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Foreword 


This volume presents the deliberations and conclusions of the individual panels making up the 
2000 Air Force Scientific Advisory Board (SAB) Summer Study, “Air Force Command and 
Control: The Path Ahead.” In this study, the Board was asked to assess the command and 
control system and the supporting communication and information systems; to consider technical 
and process improvements and to make recommendations on what should be done to “have the 
Air Force linked by 2005”; and to build toward the Air Force’s long-term command and control 
goals. There are two volumes to the report. Volume 1 presents a brief summary of the findings 
and the major recommendations. This volume, Volume 2, presents the panel reports, including 
detailed findings and recommendations. 

The study results are the product of a substantial effort by a skilled team, including panels led by 
experts in their assigned area. The study leadership wishes to thank the many individuals and 
organizations in Government and industry who contributed to the deliberations and conclusions 
presented. In addition to SAB members, many ad hoc members devoted their time. Air Force 
Major Air Command liaison officers were extremely helpful in our research and deliberations, as 
were the technical writers provided by the Air Force Academy. In addition, both the liaison 
officers and the technical writers provided outstanding administrative and logistics support. We 
gratefully acknowledge the contributions and guidance of our General Officer Participant, 
General John Jumper, Commander, Air Combat Command; and Major General Gerald 
Perryman, Jr., Commander, Aerospace Command and Control and Intelligence, Surveillance, 
and Reconnaissance Center. 

The study leaders would also like to give special recognition to the SAB Secretariat and support 
staff, in particular to Capt D. Brent Morris, the Study Executive Officer; and to Ms. Kristin 
Lynch of the ANSER team, who provided invaluable administrative and editing assistance in the 
preparation of graphics and the publication of the report. 

We believe that through the dedication of the current leadership, the Air Force has the greatest 
opportunity ever in developing an effective and efficient theater command and control system, 
and we encourage every Air Force member to seize this opportunity. 

Finally, this report reflects the collective judgment of the SAB and hence is not to be viewed as 
the official position of the United States Air Force. 
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Executive Summary 


2 

For more than three decades, the Air Force has scrutinized command and control (C ) 
modernization planning, programs, training, procedures, and architectures and has identified 
repetitive C problems in each decade. 

The Air Force Chiefs of Staff (CSAFs) have chartered numerous studies and conducted four-star 
reviews in their attempts to fix the Air Force C problem. These CSAF studies began with the 
1986 Air Force Studies Board Summer Study; this was, in turn, followed by the 1992 and 1993 
Command, Control, Communications, Computers, and Intelligence Broad Area Reviews, the 

1996 Air Force Scientific Advisory Board (SAB) Summer Study, the 1997 C 2 Task Force, the 

1997 C 2 Four-Star Summit, and this 2000 SAB C 2 Summer Study. The Air Force Chiefs of Staff 
also established a new Air Staff C Directorate, an Air Staff C General Officer Steering Group, 
and the Aerospace C 2 Intelligence, Surveillance, and Reconnaissance Center (AC2ISRC) in their 
attempts to fix C 2 . 

The redirection of this year’s SAB Summer Study from “limited forward basing” to “command 
and control” reflects the Chief of Staffs strong desire to improve Air Force C 2 capability. Each 
study made recommendations for fixing the problems the Air Force was having with C 2 . 

Analysis of the recommendations indicates that the same recommendations were made many 
times, yet the Service is not achieving the vision of linked Air Force command centers that are 
able to collaborate globally in support of all commanders in chiefs (CINCs), Services, allies, and 
the Aerospace Expeditionary Force. 

The lessons learned from DESERT STORM and ALLIED FORCE and the results of every SAB 
and Defense Science Board study have determined that U.S. aerospace power capabilities 
continue to outperform the associated C 2 capabilities. In theater C 2 , this is particularly evident in 
time-critical targeting, battle damage assessment, and campaign assessments. 

The Tasking 

The Air Force is not on a path that provides coherence across space, air, and land assets to 
support the timeliest and effective decision-making and execution. Thus, the Board was asked in 
the Terms of Reference (Appendix A) to 

• Assess the C 2 system and the supporting communication and information systems 

• Consider technical and process improvements and make recommendations on what should be 
done to “have the Air Force linked by 2005” 

• Build toward the Air Force’s long-term C 2 goals 

The specific tasks are shown below; each task had a panel to address it. Panel membership is in 
Appendix C. The SAB was to 

• Define the Air Force C 2 system with today’s capabilities and identify alternatives to enhance C 2 
over time 

• Define interoperability (joint and coalition) to ensure coordinated efforts on the battlefield 

• Identify the technologies that can enhance present and future C 2 systems, with near-term 
emphasis on timely and effective communication 



• Assess the acquisition, programmatic, and cost-effectiveness issue 

• Consider the organizational, personnel, training, and support consequences 

And we added a Bridging and Vision Panel. 

A Framework for Solution 

The Study recognized the many past organizations, directives, studies, and other efforts to 
develop a theater C 2 system for the Air Force. Many dedicated and talented leaders have made 
great efforts, and even great strides, in the name of C 2 . Yet we once again find ourselves on the 
doorstep with a basketful of comments and ideas to improve the C 2 of Air Force combat 
operations. 

It is our belief that the solution set can, and should, be cast in a framework in order to capture the 
underlying rationale for the suggestions. Our framework includes the following elements: 

• A unified, understood, focused approach to C 2 

• A process, driven by the concept of operations and based on capabilities, that encourages, not 
impedes, system operational enhancement 

• Acquisition processes that are timely and efficient in capturing emerging technologies 

• Taking the lead in becoming more interoperable, including joint and coalition operations 

• Horizontal integration of intelligence, surveillance, and reconnaissance (ISR) with C 2 

• Focus and follow-through 

Recommendations 

We recommend that the following actions be taken: 

Recommendation 1. Emphasize the Role of Command and Control in the Air Force 

It is important that all levels of the Air Force, as well as Congress and other Gover nm ent entities, 
understand the criticality of effective C 2 to the outcome of a crisis. 

Recommendation 2. Manage Theater Command and Control as an Integrated Set of 
Weapon Systems 

When an Air Force system (for example, the F-15E) is officially designated a weapons system, a 
certain formality in the management of that system, including people, hardware, software, 
training, certification, maintenance, and evolution, is established and implemented. C 2 systems 
deserve nothing less. 

Recommendation 3. Strengthen the Air Operations Center (AOC) Through Restructuring, 
Staffing, and Training 

Though the AOC is at the heart of precision air operations, recent conflicts have been 
characterized as a “pickup game” of equipment and personnel. Consequently, the efficiency and 
success of these air operations have suffered. An effective and efficient AOC, ready to deploy or 
operate from home at any time, is absolutely essential. 
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Recommendation 4. Field and Evolve the Theater Battle Management Core System 
(TBMCS) 

TBMCS has been a major, albeit painful, step to a new integrated theater C 2 system. Though it 
cannot be considered a final configuration with all modules in optimum operation, it is a major 
step forward from the previously fragmented system(s). It is time to accept the system and to 
accept the fact that continual upgrades will be needed to meet operational requirements and 
technology advances; the upgrades should be so planned. 

Recommendation 5. Institutionalize a C 2 Evolutionary Integration Process 

The major difficulty in taking advantage of developments from the military and commercial 
sectors—including off-the-shelf solutions, as well as those successfully prototyped in laboratory 
or field exercises—has been the lack of a formal and cyclical means to integrate new capabilities 
online. The Air Force should create and support a process for the evolutionary integration of 
developed modules. 

Critical to effective integration and management is the creation of a partnership, based on mutual 
support and trust, of the operators (for example, AC2ISRC); the developers (for example, the 
Electronic Systems Center [ESC] or Air Force Research Laboratory); the integrators (for 
example, ESC); and the operational testers (for example, the Air Force Operational Test and 
Evaluation Center), each of which must accept and carry out its responsibilities. 

Recommendation 6. Enable and Encourage Rapid Technology Insertion 

The Study determined that there are no technology impediments to substantial improvements in 
the effectiveness and efficiency of air operations C 2 . With some exceptions, in which additional 
operational focus is needed, the emphasis must be on the timely and effective transition of 
military and commercial technologies to the Air Force C 2 system needs. The Air Force should 
follow a focused effort to improve technology exploitation. A C 2 testbed is essential to fostering 
rapid development of the AOC and other elements of theater C 2 . 

Recommendation 7. Achieve Information Interoperability for Warfighters Through the 
Joint Battlespace InfoSphere (JBI) 

The opportunity to significantly improve our ability to conduct effective joint and coalition 
warfare rests on the degree of interoperability of the C 2 processes. The Air Force should seize 
the initiative to evolve the JBI (see Chapter 8) as the basis for true interoperability. Many 
specific nearer-term problem fixes are also important and possible. 

Recommendation 8. Staff and Train to Be Consistent With the Importance of C 2 

The Air Force has been a pioneer in recognizing the importance of its people. At the heart of this 
recognition, and built on the foundational element of “quality people” for the Air Force core 
competencies, is the establishment of a trained force of C 2 professionals. 

Recommendation 9. Strengthen Efforts for Attack of Time-Critical Targets 

Recent crises have again highlighted the shortfall in the capability for rapid acquisition, 
identification, and attack of mobile targets. Clearly, the delays in the process are unacceptable, 
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and progress in the improvement has been marginal. The Air Force should establish a program 
team to address the rapid-response attack of time-critical targets. 

Recommendation 10. Facilitate and Enhance Data Connectivity 

Critical to the dynamic management of combat airpower is the data connectivity from C 2 
activities to the aircraft. The delays in fielding solutions to the aircraft datalink problem seem to 
be more political than technical. The Air Force should exercise leadership in achieving the goal 
of interlinking aircraft based on operational access to message sets (J-series) rather than 
emphasizing only specific equipage. 

Summary 

The essence of the recommendation set is to provide focus and follow-through on C 2 issues from 
a very high level. They key actions are to 

• Establish a single C 2 ISR manager at the Air Force level (for example, a three-star operator)—an 
Air Force Council Member. 

• Integrate expert information technology professionals (internal and new) into the C 2 staff. 

• Direct a C 2 program restructuring. 

• Adopt the Global Command and Control System (GCCS) framework: evolve theater Air Force 
C 2 applications into GCCS-AF. 

• Direct a capability-centric evolutionary integration process for C 2 

• Manage theater aerospace C 2 as a system of weapon systems. 

• Baseline the number, configuration, and location of AOCs. Enhance operation and reduce 
personnel through daily “wartime” use. 

• Appoint a “lead dog” for agile combat support software systems (Global Combat Support 
System-Air Force). 

The Air Force vision of “well-equipped C 2 centers collaborating globally in support of the 
CINCs” can be rapidly achieved if senior Air Force leadership strongly endorses the need for an 
enterprise-wide C 2 capability. The Air Force must restructure the way C 2 programs are managed 
and resourced, and at every opportunity leadership must clearly speak out about their dedication 
to achieving an enterprise-wide C 2 capability. In this report we have provided a proposal for 
how the Air Force can achieve an enterprise-wide C 2 capability by 2005. We have provided our 
views on areas that the Secretary of the Air Force, Air Staff, and major command staffs should 
focus on in starting down a C 2 modernization journey. The journey of achieving an effective 
distributed, collaborative, enterprise-wide C 2 capability that allows C 2 centers to collaborate 
globally in support of the CINCs is one of the most important journeys the Air Force must take 
in the 21st century. 
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Chapter 1 
Introduction 


1.1 Introduction 

This chapter provides the background and context for the Air Force Scientific Advisory Board’s 
(SAB’s) study on improving command and control (C 2 ). Previous studies and actions to enhance 
the Air Force’s C 2 capability over time are reviewed in an effort to advocate the view that 
substantial change in management and resource allocation is required to fix long-term 
limitations. The history suggests that, as an institution, the Air Force has not found an effective 
way to change the system. The value of C is discussed to persuade the reader that greater 
importance must be accorded C 2 as a weapon system. There has been considerable debate about 
intelligence, surveillance, and reconnaissance (ISR) as a part of C 2 . The study team considers 
ISR an essential element of operational and tactical C 2 . This chapter describes how the Theater 
Command and Control System fits into the overall C 2 capability. Finally, the chapter advocates 
the need for the management of combat information to reduce the burden on the warfighter, who 
is so increasingly overloaded with information that it is difficult to find what is needed. 

Volume 1 presented the summary of the study findings and a brief recap of the key 
recommendations. This volume, Volume 2, provides the detailed reports of the panels, including 
their charter, approach, and visit and briefing trail. Each panel’s chapter provides a more 
extensive set of recommendations. 

1.2 History—“Lessons Learned” 

For more than three decades, the Air Force has scrutinized C 2 modernization planning, programs, 
training, procedures, and architectures and has identified repetitive C 2 problems in each decade. 
There have been many failed attempts in the 1970s, 1980s, and 1990s to fix these repetitive 
problems and this SAB Summer Study in 2000 kicks off the fourth decade of analysis in finding 
the needed fixes. 

The redirection of this year’s SAB Summer Study topic from limited forward basing to C 2 
reflects the Chief of Staffs continuing concern about improving Air Force C 2 capability. Each 
study made recommendations for fixing the problems the Air Force was having with C 2 . 

Analysis of study recommendations indicates that the same recommendations were made many 
times, yet the Service is not achieving the vision of Air Force command centers that are linked 
and have the ability to collaborate globally in support of all commanders in chiefs (CINCs), 
Services, allies, and the Aerospace Expeditionary Force. 

The lessons learned from DESERT STORM and ALLIED FORCE and the results of past Air 
Force SAB and Defense Science Board studies have determined that U.S. aerospace power 
capabilities continue to outperform the associated C 2 capabilities. This is particularly evident in 
theater C 2 of time-critical targeting, battle damage assessment, and campaign assessments. 

1.3 C 2 and the Theater Aerospace Command and Control System (TACCS) 

TACCS is only one part of the overall joint C capability of the Department of Defense. CINCs 
of the regional and functional commands each have C 2 systems. TACCS defines the capability 
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to support a Joint Forces Commander and the Joint Forces Air Component Commander in daily, 
crisis, or combat operations. TACCS must interface with other component commanders and 
specifically with Space Command, Special Operations Command, and Transportation Command 
C 2 systems. This study includes assessment and recommendations for improving all Air Force 
C 2 capability but focuses on theater C 2 as reflected in the terms of reference. 

1.4 The Value of Theater Command and Control 

Theater C is defined as the processes and systems that the commander uses to develop the 
strategy, to plan operations, to control execution, and to assess the effects in crisis or combat. 
While the well-defined principles of C 2 remain valid, the rapid improvements in combat aircraft 
and sensor capabilities are driving the need for more rapid decision-making processes. New 
concepts of operations—including effects-based warfare, precision strike, and flex targeting to 
attack moving or movable targets—all require integration and synchronization of larger and 
diverse forces. 

Commanders need to optimize force application to rapidly achieve objectives and end the 
conflict quickly. Enhancing C 2 means reducing the decision cycle time to significantly shorter 
timelines than the adversary’s. This enables the commander to dynamically gain the initiative 
and respond to opportunities. The key elements of dynamic C 2 are knowledge of the adversary, 
real-time knowledge of the battlespace, distributed knowledge of the commander’s intent, 
decentralized execution, dynamic control of sensors and shooters, and real-time assessment of 
effects. C 2 must be improved in order to improve our force effectiveness today and to be 
prepared to exploit the capabilities of our future forces such as the F-22, the Joint Strike Fighter, 
the airborne laser, and other systems. 

1.5 ISR in Command and Control 

Commanders need information and knowledge to make effective decisions in all elements of 
combat or crisis operations. As the speed of operations accelerates, commanders require more 
responsive processes for decision-making. Because of their traditional use of ISR to gather 
information of strategic value, control of those assets has been retained at the very high levels 
and priority given to collection for Washington decision makers. There is a growing recognition 
that those assets need to support the Joint Task Force (JTF) Commander. Significant 
improvements have been implemented and others planned to make these systems more 
responsive to the dynamics of combat and crisis operations. U.S. Space Command has 
implemented a number of support concepts to aid the supported CINC and the JTF Commander. 
Other assets, such as the Joint Surveillance Target Attack Radar System and the Predator and 
Global Hawk unmanned aerial vehicles, have been designed to give the operational commander 
dedicated assets to support operations. 

Integration of this capability is essential to optimize the commander’s knowledge of the 
battlespace. Sensor management is an integral part of C 2 . The only way to speed the planning 
and execution process is to dynamically manage the ISR assets. Combining ISR and combat 
aircraft to find and destroy moving or movable targets requires the dynamic execution of both 
capabilities. Therefore the study concluded that ISR is an essential element of C 2 . 
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1.6 Combat Information Management 

Dynamic battle management requires the management of information. Joint Vision 2010 defines 
the goal of information dominance. But information dominance implies more than just obtaining 
information: it means converting that information to a complete understanding of the situation 
and sharing that understanding with decision makers at every echelon at the right time, in the 
right format, and at the right level of detail. The amount of information available to commanders 
today has increased dramatically in both quantity and quality. But possession of large amounts 
of information does not necessarily enhance C 2 . Information overload; lack of interoperability; 
immaturity in fusion; outdated tactics, techniques, and procedures (TTPs); and the lack of an 
information operations function all contribute to latency in decision making. 

This Study recognizes the need to enhance C 2 by creating an information management capability, 
including trained staff; TTPs; and support tools to control access and ensure dissemination to 
authorized users. The SAB studies on C 2 in 1996 and on information management in 1998 and 
1999 are recommended for further understanding of this issue. 

1.7 Summary 

The chapter provides the foundation and context for the remainder of the report. The Air Force’s 
documented difficulty in achieving the needed capability of C 2 as well as the value of C 2 in 
today’s and future operations should stimulate the reader to understand the study’s conclusions 
and recommendations. The importance of ISR and combat information management is also 
included. 

What follows are the reports of the individual panels making up the study team. The reports are 
organized with the panel’s detailed findings and recommendations included in those chapters. 


1-3 



(This Page Intentionally Left Blank) 


1-4 



Chapter 2 

Concept and System Definition Panel 


2.1 Introduction 

The 1996 Air Force Scientific Advisory Board (SAB) Command and Control (C 2 ) study stated, 
“Systems are stovepiped from the very beginning in terms of how they are defined, funded, 
advocated and managed by the Air Force.. .The stove piping problem extends to the very core of 
how forces are equipped.” An additional theme is reflected in Einstein’s words: “The world we 
created today has problems which cannot be solved by thinking the way we thought when we 
created them.” Achieving the Air Force Chief of Staffs (CSAF’s) goal of linking together Air 
Force C 2 requires that we not only, look back at what the Air Force has already tried in the past, 
but also follow Einstein’s advice and fundamentally change the way the Air Force thinks about 
C 2 . 

2.2 History “Lessons Observed” 

CSAFs have chartered numerous studies and conducted many four star reviews in their attempts 
to “fix” the Air Force C 2 problem. These CSAF studies began with the 1986 Air Force Studies 
Board Summer Study, this study was, in turn, followed by 1992 and 1993 Command, Control, 
Communications, Computers, and Intelligence (C 4 I) Broad Area Reviews, 1996 SAB Summer 
Study, 1997 C 2 Task Force, 1997 C 2 Four-Star Summit, and this 2000 SAB C 2 Summer Study. 
The CSAFs also established a new Air Staff C 2 Directorate, an Air Staff C 2 General Officer 
Steering Group, and the Aerospace C 2 Intelligence, Surveillance and Reconnaissance (ISR) 
Center in their attempts to “fix” C 2 . 

The redirection of this year’s SAB Summer Study from “limited forward basing” to “C ” reflects 
the CSAF’s continuing frustration with Air Force C 2 capability. Each of the past studies made 
recommendations for fixing the problems the Air Force was having with C 2 . Analysis of study 
recommendations indicates that the same recommendations were made many times, yet the 
service is not achieving the vision of Air Force command centers that are linked together and 
have the capability to collaborate globally in support of all commanders in chiefs (CINCs), 
services, allies and the Aerospace Expeditionary Force (AEF). 

2.3 Commitments and Culture 

A thorough review indicates that the recommendations of this study are consistent with those of 
past studies on Air Force C 2 . For 10 years the Air Force has accurately and repeatedly identified 
its C 2 problems, worked the margins, and not made substantial progress in resolving these 
persistent problems. The Air Force’s fragmented and stovepiped major air command 
(MAJCOM) views of C 2 are the result of a weak Air Force commitment to the importance of 
enterprise-wide Air Force C 2 capability. In addition, the Air Force system of education, training 
and operations does not inculcate current and future leaders with an abiding awareness that C 2 is 
the foundation upon which all the Air Force core competencies are built. Consequently, Air 
Force management of its C 2 enterprise, throughout its history, has lacked vision and a constancy 
of purpose. All the good intentions and actionable recommendations of today will be stacked 
with those of yesteryear’s studies unless senior leadership demands an enterprise-wide view of 
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C and is committed to building the capability. The leadership must also ensure that this 
enterprise-wide C 2 capability is trained and operated in peacetime, as it will operate in wartime. 
Air Force MAJCOMs do not go to war individually, but team together in support of all CINCs, 
services, allies and the AEF. Therefore an enterprise-wide C 2 system is needed. 

2.4 Establishing and Managing the Air Force C 2 Enterprise 
2.4.1 Institutionalizing Enterprise-Wide C 2 

A clear vision must guide any organizational transformation by motivating and compelling its 
people. A C 2 vision should be short and simple, capturing C 2 as the core business of the Air 
Force. It should re-enforce the doctrinal value of centralized planning and decentralized 
execution, provide a theater perspective, and clarify the command relationships to achieve unity 
of command. Such a vision of Air Force C 2 exists. It was documented in the Aerospace 
Command and Control, Intelligence, Surveillance, and Reconnaissance Center’s (AC2ISRC’s) 
USAF C 2 CONOPS, Dynamic Aerospace Command—USAF Command Centers Collaborating 
Globally in Support of all CINCs, services, allies and the AEF. It should be embraced by the Air 
Force leadership and institutionalized. Such a vision, backed by senior leadership’s commitment 
to transformation, will enable the Air Force to embrace a true understanding of C 2 as the life¬ 
blood to Global Vigilance, Global Reach, and Global Power. The Air Force also needs to follow 
the Joint Staffs Joint Vision 2010 ( JV2010 ) lead and elevate C 2 to a prominent role in its vision. 

Recommendations 

• Endorse and institutionalize a compelling C 2 vision—the first step to recognizing the essential 
link between aerospace power and C 2 . (CSAF) 

• Add an enterprise-wide vision of C 2 to the Air Force Vision Statement to ensure that C 2 becomes 
the foundation for Air Force core competencies (CSAF) 

• Ensure that this Air Force C 2 vision supports the JV2010 and FV2020 visions 
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2.4.2 C 2 , The Foundation of the Global Engagement Arch 



AIR & SPACE POWER 


Command and Control 


2025 JOINT FORCE TEAM 


Figure 2-1. The Global Engagement Arch 

Effectively accomplishing the Air Force mission depends on how C 2 is performed. As a result, 
C 2 should be viewed, along with quality people, as the foundation of the Global Engagement 
Arch. It is the enabler for the effective employment of Aerospace Power. The Key to achieving 
an elevated role for C 2 and the vision of “command centers collaborating globally” is to establish 
an empowered single manager for C 2 at Air Force level. 

Recommendations 

Establish a single manager for C2 at Air Force level (CSAF) 

Individual should 

• Be an Air Force Council member 

• Have C2 operational experience 

• Be empowered to propose solutions to cross-program and MAJCOM issues 

• Be the Air Force Chief Information Officer (CIO) and represent the Air Force at the Department 
of Defense (DoD) CIO Panel 

• Have assigned directors, to include C2, Communications, ISR, and Agile Combat Support and 
have appropriate liaisons/DRUs 

• Hire skilled Information Technology experts and C2 professionals for key positions. IP As should 
be considered for these positions. 

• Be responsible for publishing a single Air Force C2ISR Strategic Plan that provides 
comprehensive Air Force direction for C2 operations, modernization and sustainment 

• Define and sponsor a unifying infrastructure approach to system development 
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2.4.3 The Air Force C 2 System and Enterprise-wide C 2 Management 

The lack of understanding of the Air Force C 2 vision and constancy of purpose is evident at 
many levels. Examples are: the excessive number of Program Element (PE) Codes spread 
across too many panels in the Air Force Corporate Process; too many offices in charge of 
different parts of the same C 2 system, no central Global Command and Control System (GCCS) 
management structure aligned with Joint Staff instructions; confusing placement of AC2ISRC 
under a MAJCOM while it holds Air Force-level responsibilities, and so on. This lack of 
coherent, focused management at the Air Force leadership level has fostered stove piped C 2 
systems, multiple disparate improvement efforts striving for similar outcomes, confused training 
requirements, inadequate manning, and difficulty in deciding on a baseline C 2 structure. 

The Air Force also needs to view its C 2 system as an integrated system of weapon systems that is 
composed of many C 2 centers or nodes. Each is managed as a “weapon system” and has a 
Designed Operational Capability Statement, operational qualifications, currency requirements, 
and inspection programs. In addition, the Air Force should manage these C 2 weapon systems 
with the same job performance and safety standards as it does other weapon systems that have 
life-and-death operational consequences. The goal of a C 2 improvement program should be a 
distributed and collaborative system of systems operated by certified C 2 warriors. Additionally, 
an effective C capability requires an effective Common Operational Picture (COP) that not only 
correlates data, but also fuses information into knowledge for the decision maker. The COP’s 
role in Air Force C 2 is crucial because it will dictate the nature of information management at all 
theater levels, from the weapons system displays to the theater CINC or Joint Task Force 
Commander’s operational picture. 

The following recommendations are the result of applying an Air Force enterprise-wide view of 
C 2 to the Air Force Planning, Programming, and Budgeting System; the Requirements System, 
the Acquisition System and C 4 I Support plans. There are six fundamental components of the 
enterprise-wide C 2 weapons system: (1) individual command centers and nodes, (2) C 4 I software 
applications, (3) C 4 I software infrastructure, (4) communications infrastructure (5) the 
information infrastructure and (6) Air Force sensor programs. 

Following is a detailed description of the six major components of the C weapons system: 

1. Individual C 2 Command Centers and Nodes : The foundation of this Air Force enterprise- 
wide view is C centers and nodes that are managed as an integrated weapons system 
consisting of people, processes, and technology. These C 2 Centers are operated by many 
MAJCOMs and must be manned by highly trained and certified C 2 warriors. The C 2 warriors 
are not only highly skilled, for example, in the combat, mobility, space, and special 

operations missions but also in the art and science of the application of aerospace power in 

2 

joint and combined operations. Fundamental to the success of the proposed Air Force C 
weapon system concept is an enterprise-wide vision of a globally collaborating partnership of 
Air Force C 2 centers and nodes. These C 2 centers and nodes bring to the CINCs a multi- 
MAJCOM C 2 capability that is far greater than the sum of its parts. Each weapon system 
node is funded by a program element that funds manpower, communications and computer 
equipment, facilities, and sustainment. All program elements should be assigned to a single 
C 4 I panel in the Air Force Corporate Process. Each node has a concept of operations 
(CONOPS) and a set of training publications—such as Air Force Instructions (AFIs) and 
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tactics, training, and procedures (TTPs)—that describes its responsibilities within the 
enterprise-wide C 2 system and how it functions in the multi-Service and joint enterprise-wide 
C 2 system. Each node should also have a C 4 I Support Plan that describes its configuration 
control process and how it will be sustained. Finally, weapon system nodes should have a 
supporting System Program Office and an Acquisition Program Management Decision. The 
CONOPS, Operational Requirements Documents (ORDs), PEs, Program Management 
Directives (PMDs), Program Managers (PMs), C 4 I Support Plans (C 4 ISPs) and Mission Area 
Plans (MAPs) need to be redrafted and/or reorganized so that they all align by weapon 
system node. For example the air operations center (AOC) (and all other nodes in the system 
of weapon systems) needs it’s own CONOPS, ORD, PE, PMD, PM, C 4 ISP, etc. Aligning 
these documents and entities by node is key to achieving the Air Force C 2 vision of 
“command centers collaborating globally.” The system of weapon systems should be 
described and defined in one overarching CONOPS, one Strategic Plan, one Capstone 
Requirements document, etc. A single integrating PMD should also be written to direct the 
various MAJCOMs and agencies to take the actions necessary to achieve the Air Force C 2 
vision. Well-defined actions should be spelled out in this integrating PMD. See 
Appendix 2D for a matrix table depicting the above concept. 

2. C 4 I Applications'. C 4 I applications are the software information-processing and decision 
tools of the C 2 Weapons System. Not every C 2 center may use the same C 4 I applications. 
Some applications will be common across all C 2 centers; however, other applications will 
provide specialized capability. For example, Air Mobility Command (AMC) or Space 
Command may use applications that Combat Air Forces do not use, such as AMC’s C 2 
Information Processing System or Space Command’s Space Battle Management System. 

3. Software Infrastructure : The software infrastructure should be the common software 
foundation that supports all C weapons systems nodes. It is common across all MAJCOMs, 
CINCs, and Services. All C 4 I applications and software infrastructure development efforts 
should be consolidated under two programs: the Global Command and Control System-Air 
Force (GCCS-AF) and GCCS-AF Real Time Weapons Control. The requirements for these 
two programs should be identified in a single ORD for each program and each program must 
have a single PE, PMD, MAP, and C 4 ISP. Both programs should be consolidated on a single 
C 4 I panel within the Air Force corporate process. Information systems that support agile 
combat support tracking and decision-making should be developed under the GCCS-AF 
program. 

4. Communications Infrastructure : The supporting communications infrastructure is divided 
into four areas: (1) tactical communications, (2) base-level communications, (3) long-haul 
communications, and (4) satellite communications. Requirements for the communications 
infrastructure should be identified in a single ORD, and funding provided in a single PE for 
each of the four areas. All four programs should be consolidated on a single C 4 I panel within 
the Air Force corporate process and have a single MAP and C 4 ISP. 

5. Information Infrastructure : The information infrastructure consists of three parts: 

(1) common information management, (2) datalinks, and (3) Joint Interoperability Tactical 
Command and Control Systems message sets. All three areas should be consolidated under a 
single GCCS-AF Integration Program and have a single CONOPS, ORD, PMD, MAP, and 
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C 4 ISP. All three programs should be consolidated under a single C 4 I panel in the Air Force’s 

Corporate Process. 

6. Air Force Sensor Programs : The platforms associated with these programs are outside the 

C 2 Weapons System; however, they are the eyes and ears of C 4 I, and the information they 

provide is a fundamental part of the C 2 weapons system. 

The above proposal would greatly simplify what are now complex and fragmented C 2 programs 
into fewer logical and well-defined and -understood components of the C 2 weapons system. 

Recommendations 

Formalize the definition of the C 2 system of C 2 weapon systems and nodes 

• Develop and align an overarching family of C 2 CONOPS (AF/XO) 

• Develop and align C 4 ISPs to the C 2 Weapon Systems and nodes (AF/SC) 

• Develop a capstone PMD with subordinate PMDs and System Program Offices that are aligned 
with the family ofC 2 CONOPS (AF/XO) 

• Merge the C&I Support Plan and the C 2 ISR Campaign Plan into a single Air Force C 2 Strategic 
Plan (Air Force CIO) 

• Restructure programs and PEs by using the C 2 System of Weapons System and nodes and links 
concept (AF/XP) 

• Designate the individual C 2 centers and nodes as weapon systems and inspect, train, and operate 
them as such (AF/XO) 

Create and fund a C 2 integration program 

• Establish a C 2 Integration Program Office that is empowered to direct and coordinate all 
interoperability development between C 2 centers and nodes (SAF/AQ and AF/XO) 

• Create and maintain a capabilities-based C 2 Weapons System Roadmap and review it regularly 
(AF/XO) 

• Create and maintain a cross-program C 2 Weapon Systems Integration Roadmap to monitor 
progress and for review by the CSAF and the Secretary of the Air Force (SAF) annually at the C 2 
capabilities-based Quarterly Acquisition Program Review (SAF/AQ and AF/XO) 

• Develop a long-term strategy for cultivating the Joint Battlespace InfoSphere (JBI) and fund it 
(AF/XP and AF/XO) 

• Establish the Integration Task Force as per AFI63-123 (AF/XO) 

2.5 Expeditionary Air Force C 2 Baseline 

The Expeditionary Air Force C system of systems is a subset of the Air Force C enterprise¬ 
wide C 2 system and is composed of the continental United States (CONUS) based command and 
intelligence centers and of the Theater Air Control System with its supporting airlift C 2 
capability. The various nodes are operated by numerous MAJCOMs and agencies. Therefore, 
overall management and integration of this system of systems that will “collaborate globally in 
support of the CINCs” must be accomplished at the Secretariat and Air Staff levels of the Air 
Force. 
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2.5.1 Expeditionary Aerospace C 2 System Components 

This section describes the existing C 2 centers (see Figure 2-2) that support a commander’s 
capability to plan, direct, coordinate, and control forces to accomplish assigned missions. 



Figure 2-2. Expeditionary Aerospace C 2 System Centers 


2.5.2 The Theater Air Control System 

Air Force forces (AFFOR) respond to worldwide missions in support of theater CINC missions 
that require deployment of Air Force C capability. At the operational level of warfare, C 
weapons systems provide Air Force C 2 in support of the Aerospace Expeditionary Task Force 
Commander, Commander, Air Force Forces (COMAFFOR), and the Joint/Combined Force Air 
Component Commander (J/CFACC). 

Air Force Forces Headquarters (HQ): The mission of the AFFOR HQ is to plan, monitor, 
execute, and assess Air Force operations and sustainment in support of COMAFFOR. It is 
functionally separate from the AOC’s air operations planning and execution activities; however, 
AFFOR activities fundamentally affect the air campaign by both enabling and constraining air 
operations. The AFFOR HQ is COMAFFOR’s C 2 element. COMAFFOR C 2 has two facets: 
operational and service. The operational commander handles technical, administrative, and 
tactical matters. The service element manages the “beds, beans, and bullets” issues. 

Combined Aerospace Operations Center (CAOC): The overarching mission of the CAOC is 
to employ decisive joint and coalition aerospace power through effective C 2 in support of aligned 
commands and CINCs worldwide. The CAOC is the operational C 2 center in which the CFACC 
has centralized the functions of planning, direction, and control over aerospace resources. The 
CAOC performs duties in support of the C/JFACC, the Airspace Control Authority and the Area 
Air Defense Commander. The CAOC produces, distributes, and executes the integrated air 
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tasking order (ATO). Individuals representing joint, coalition and/or allied forces assist in the 
operation of the CAOC. 

Control and Reporting Center (CRC): The CRC is directly subordinate to the CAOC and is a 
primary control node concerned with decentralized execution of air operations. The CRC directs 
region or sector air defense and provides aircraft control and monitoring for both offensive and 
defensive missions. The CRC also may establish liaison with allies or components to exchange 
airspace management and air defense data from related control systems. 

Control and Reporting Element (CRE): The CRE is subordinate to the CRC and augments 
the CRC’s mission by extending radar surveillance and airspace control capabilities within the 
area of responsibility. 

Air Support Operations Center (ASOC): The ASOC is directly subordinate to the AOC and 
is the primary liaison element to the corps headquarters for air support. It is primarily concerned 
with the exchange of combat information between air and ground units for immediate air support 
of ground operations. It plans, coordinates, and directs tactical air support of ground forces, 
normally at corps level or below. The ASOC is delegated execution authority to provide fast 
reaction to requests for offensive air support such as close air support (CAS) or air interdiction. 

Tactical Air Control Party (TACP): The TACP is subordinate to ASOC and responsible for 
controlling close air support and advising and assisting the U.S. Army commander when air 
support is required. 

Wing Operations Center (WOC): The WOC, both fixed and deployed, includes the following 
functional areas: operations control, maintenance coordination, reports, training, and battle 
management and survival recovery. MAJCOMs, in coordination with assigned or supported 
CINCs, may specify additional functions for collocation or removal from the WOC. 

Tanker Airlift Control Element (TALCE): The TALCE coordinates and executes both 
preplanned and immediate airlift requirements with Tanker Airlift Control Center (TACC) and 
the Air Mobility Division (AMD) within the AOC. The TALCE reports to the Air Mobility 
Element within the AMD of the CAOC. TALCE cadre members are responsible for conducting 
airfield assessments worldwide. TALCEs are provisional, deployed organizations composed of 
various mission support elements, established at fixed, deployed, and en route locations where 
operational support is non-existent or insufficient. 

2.5.3 Theater Airborne C 2 Assets 

Airborne Warning and Control System (AWACS): AW ACS performs missions designed to 
extend radar coverage, enhance link operations, assist in track identification, and gather 
intelligence data. AWACS provides all-weather, all-terrain target detection, weapons control, 
and threat warning. AWACS provides area surveillance and control when ground radars are not 
in place, augments operational radars, supports air operations conducted in support of ground 
forces, and provides surveillance, early warning of hostile aircraft, control of fighter aircraft, 
airspace management, and ADA coordination functions during contingency operations. 

Airborne Battlefield Command and Control Center (ABCCC): The ABCCC operates as part 
of the Airborne Elements of the Theater Air Control System. Its primary function is to provide 
management of tactical air forces and to liaison with ground forces. Its general employment role 
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is an extension of AOC combat operations and as an alternate ASOC/Direct Air Support Center. 
However, an integrated battle management and communications system onboard the EC-130E 
aircraft enables the battle staff to provide air and ground component commanders with a flexible 
airborne C 2 capability. 

Joint Surveillance Target Attack Radar System (JointSTARS): JointSTARS provides 
dedicated support to ground commanders for planning and execution of the land battle and 
theater air interdiction campaign. JointSTARS is a theater-wide battle management C 2 platform 
that conducts ground surveillance to develop an understanding of the enemy situation. 
JointSTARS also provides attack support functions to friendly offensive air elements. 

A-10 Forward Area Controller (FAC-A): TACP operating from a suitable aircraft, the FAC-A 
coordinates air strikes between the TACP and CAS aircraft. The FAC-A provides terminal 
control, relays CAS reports, provides immediate target and threat reconnaissance, and marks 
targets for the attacking aircraft. The FAC-A can perform tactical battle management by cycling 
the CAS flights through the target area, while prioritizing the targets in coordination with the 
friendly ground force. 

2.5.4 Supporting CONUS Command Centers 

The following Air Force Commander in Chief, U.S. Space Command (USCINCSPACE) and 
U.S. Transportation Command centers provide critical support for successful Expeditionary 
Aerospace Force’s (EAF’s) operations in support of the CINC. 

Air Force Space Command (AFSPACE) AOC: The AFSPACE AOC facilitates the 
integration of information and resources, implements and coordinates the Commander, 
AFSPACE (COMAFSPACE) tasking and priorities, makes recommendations to superiors, and 
validates and prioritizes requests for USCINCSPACE. The 14AF AFSPACE AOC is an in-place 
equivalent of the theater AOC and accomplishes parallel planning and operational functions for 
COMAFSPACE 

Tanker Airlift Control Center (TACC): The TACC, Headquarters AMC, located at Scott Air 
Force Base (AFB), IL, is the command’s hub for planning, scheduling, tasking, and executing 
America’s mobility forces around the world. The TACC is dedicated to providing quality 
service to a wide range of mobility customers. In effect, the TACC is “one-stop shopping,” 
which brings requirements and capabilities together to accomplish AMC’s Global Reach mission 
efficiently and effectively. 

Air Force Information Warfare Center (IWC): The Air Force Information Warfare Center at 
Kelly AFB, TX, engages in a myriad of activities supporting its role as the Air Force Information 
Warfare executive agent. Its mission is to develop, maintain, and deploy information warfare 
and C 2 warfare capabilities in support of operations, campaign planning, acquisition, and testing. 

2.5.5 Operational and Systems Architecture Development Factors 

Each of the above centers is responsible for a variety of C 2 functions which are supported by a 
“business process” that is defined in an operational architecture and information technology 
systems and by communications that are defined by a systems architecture. This section offers 
an analysis of operational and systems architecture development factors. 
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The C system is a system of systems (as shown in Figure 2-3). The large majority of individual 
elements that make up the overall C 2 system are contributed by non- C 2 organizations. In fact, 
the unique functions of the C 2 system are planning and execution control. 

Elements of each C 2 System are unique to the theater or crisis. These include the specific 
allocated ISR assets, weapon delivery platforms, communications, combat support, and 
information management systems. 

Additional assets may be available on a shared basis to the commander and augment the organic 
systems—specifically, strategic ISR and information management systems, long-range weapon 
delivery platforms such as B-2s, long-haul communications, and logistics and combat support 
systems. 

The interactions between these systems in a C 2 context are dominated by information exchanges, 
principally in the form of tasking, collected sensor data, and system status and capability 
reporting. 


The nature of systems of systems is that the user does not have the option to specify the nature of 
the interfaces between the component systems. It is thus incumbent on the system architects and 
acquisition organizations to assure that, to the extent possible, operational systems conform to 
interface standards that enable the user to configure a system of systems that meets the needs of 
the particular situation. The set of interfaces that are appropriate include those implemented by 
the systems of the other Services and U.S. allies. 
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Figure 2-3. Existing C 2 System Architecture 


The component functions that make up the Planning and Execution Control Process (see 
Figure 2-4) include assessment, strategy decision, planning and resource allocation, and dynamic 
execution. Assessment includes the analysis of ISR data and the characterization of the current 
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situation. Strategy decisions set the objectives of the campaign and describe the desired effects 
to be achieved by aerospace power. The planning process leads to allocation of available 
resources as reflected in taskings levied on organic weapon systems, ISR assets, communications 
resources, and combat support organizations. Some taskings are requests for resources held at a 
higher level that may or may not be granted. To the extent that these requests for shared 
resources are not satisfied, the associated plans will have to be adjusted or alternative courses of 
action initiated to accommodate the deficiency. 

Once the plan begins execution, adaptation and adjustment will be necessary to fix evolving 
problems and maintain the initiative. 



Figure 2-4. Planning and Execution Management 


The planning and resource allocation process in an AOC is responsive to the individual mission 
areas and functions that staff the AOC. These include air interdiction, airlift, close air support, 
combat search and rescue, communications, defensive counter-air, information operations, 
intelligence analysis, ISR collection management, logistics, offensive counter-air, special 
operations strike, suppression of enemy air defenses, and tanker support. 

The above sections of this report started with a concept of an Air Force enterprise-wide view of 
C 2 that could be used to pull together and link C 2 within the Air Force. We also added more 
“meat on the bones” on managing C 2 as a weapons system and proposed a concept for the 
Expeditionary Aerospace C 2 System. The Expeditionary Aerospace C 2 System comprises 
globally linked command centers and nodes with C 2 -assigned forces and is trained and equipped 
to collaborate in support of the theater CINCs and Joint Force Commanders (JFCs). This next 
section focuses on the theater subset of the Expeditionary Aerospace C System. 
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2.6 Building the Future—The Theater Aerospace Command and Control System 
(TACCS) 

2.6.1 Combined Aerospace Operations Center 

The possibility that an Air Force-provided AOC will operate in war as a “U.S.-only” command 
center is highly remote. Theater air operations will be combined operations. As a result, the 
design of the AOC weapons system must deal with the security issues associated with 
multinational air operations. The SAB believes that these requirements not adequately addressed 
in the AOC Weapons System requirements and are not adequately addressed in its system 
architecture design. 

This section presents significant issues that will affect a commander’s ability to plan and execute 
an air campaign. The SAB proposes the following approaches to improve Air Force CAOC 
organization, training, and equipage. 

2.6.2 CAOC/AOC Organization 

The organization of the Theater Air Control System is well defined and documented, with the 
exception of the CAOC/AOC. Air Force AOCs support a wide variety of CINCs throughout the 
world. The fact that these Air Force AOCs support a wide variety of commands often results in 
extensive customization. Other Air Force weapon systems are not customized for each theater of 
operations. CAOC/AOC should follow the “organize, train, and equip” concept the Air Force 
uses for other major weapon systems, such as the F-15, F-16, and AW ACS. These are not 
customized by theater, but provided by the Service to the theater as a combat capability package. 

The CAOC is the operational C center in which the CFACC has centralized the functions of 
planning, directing, and controlling aerospace resources. The probability that the Air Force will 
operate a “U.S. only” AOC is extremely remote, yet many of our development efforts do not 
address the underlying coalition security and system engineering issues in the technical design of 
the AOC systems infrastructure. Coalition operations must be viewed as the operational baseline 
of the CAOC/AOC Weapon System and, as a result, become the driving force behind its 
organization, technical design, and systems engineering. The following is a description of its 
basic organizational structure. 

CAOC Divisions: The CAOC/AOC has five core divisions. 

Strategy Division: The Strategy Division develops, refines, disseminates, and assesses the 
progress of the JF ACC’s aerospace campaign strategy. 

Combat Plans Division: The Combat Plans Division is responsible for Joint Aerospace 
Operations Center (JAOC) near-term aerospace operations planning. It refines, disseminates, 
and assesses the progress of the JFACC aerospace strategy. It also prepares and refines two 
ATOs beyond the executing ATO. 

Combat Operations Division: The Combat Operations Division executes the ATO. It 
analyzes, prioritizes, and, if necessary, recommends redirection of assets to the JFACC. It also 
coordinates emergency air support requests. 
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Intelligence, Surveillance, and Reconnaissance Division: The ISR Division provides 
integrated distribution of ISR information and processes. It also develops, plans, and coordinates 
all aspects of ISR capabilities for the planning, execution, and assessment responsibilities of the 
CAOC/AOC. 

Air Mobility Division: The Air Mobility Division plans, coordinates, tasks, and executes 
intratheater and intertheater air mobility forces. It coordinates aerial refueling plans, tasks, and 
schedules. The Air Mobility Division ensures that air mobility missions are visible in the AMC 
standard C system and reflected in the ATO/Airspace Control Order. 
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Figure 2-5. CAOC/AOC C 2 System Operational Relationship 


CAOC/AOC Combat Operations Staff: An AOC is led by an AOC Director, has five 
divisions, and multiple support teams. As an example, the following are brief descriptions of 
principal positions in a combat operations division. 

CAOC/AOC Director: The AOC Director is responsible for the centralized planning, directing, 
controlling, and coordination of air effort and all JFACC assets. Responsibilities of the Director 
include supervising the five AOC divisions and approving, as well as releasing for publication, 
the ATO. The AOC Director also monitors, evaluates, and adjusts as necessary to meet changing 
tactical situations while executing the ATO. The AOC Director advises the commander of 
problems or factors affecting achievement of assigned objectives. 
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Director of Combat Operations (DCO): The DCO works for the AOC Director and is in 
charge of 24-hour operations in the Combat Operations Division (COD). The COD is 
responsible for the current ATO during execution and for making necessary changes to affect the 
theater air operations. 

Chief, Combat Operations (CCO): The CCO reports directly to the DCO and has overall 
responsibility for the direction and supervision of the COD. The CCO ensures that current 
operations correspond to JFC/JFACC/AFFOR directives and is responsible for maintaining 
viable air and missile warning as well as defense operations. At the discretion of the AOC 
Director, the CCO may be the senior officer within the COD. 

Senior Offensive Duty Officer (SODO): The SODO’s main role is to monitor ATO execution 
and make recommendations to the CCO. The SODO exercises authority over offensive and 
support operations. The SODO supervises the individual mission cells and weapon system 
experts who augment those positions. The SODO’s main role is to monitor ATO execution, 
recommend changes to the ATO, and manage mission and strike package retasking as directed 
by the CCO. 

Fighter Duty Officer: The job of Combat Operations duty officers is to be the expert in their 
assigned aircraft and/or mission specialties. They represent the concerns of their deployed and 
employed units and act as a conduit for information between their units and the AOC leadership. 

The SAB suggests reorganizing the CAOC using the joint staff structure. This results in a widely 
understood CAOC organization that is fully compatible with all other Services’ and CINCs’ 
organizational structures. 




A-1 
(Personnel) 
Manpowjg 





NAF/JFACC 

Director 



A-2 
(Intel) 
Fusion 

Collection Mgt 
Target Plannir 
Weapon nerintj 
Cmbt Assessmnt 




A-3 

(Ops) 

ATO Execution 
ATO Change 
TCT 

Training and 
exercise 



A-4 

(Log/Mof 

Transpori 
Supply/p 
Munitions 
TPFJ3D Flows 


I 


A-5 

(Plans & Str) 

JGAT 

SPINS 

Air Defense Plan 
Publish ATO 

Strategic Plan 
JFACC Guidance 
OPS Assess 


Js*' 

omm) 


DIRMobFor 
TALCE 


Figure 2-6. Proposed AOC Joint Organizational Structures 


Recommendations 

Build CAOCs—not AOCs. Deal with the security and weapons system design challenges up 
front (AF/XO) 

Reorganize the CAOC using the joint organizational model (AF/XO) 
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2.6.3 AOC Process Issues 


While the fundamental mission of every CAOC/AOC is similar, each theater performs CAOC 
functions differently. Historically, there has been little effort to standardize CAOC operations. 
The North Atlantic Treaty Organization Allied Tactical Air Forces (ATAFs) each planned and 
executed their air campaigns using different procedures and equipment. For example, CONUS 
augmentees to the 2ATAF CAOC in northern Germany, known as the Allied Tactical Operations 
Center, would find very different procedures and processes from those found in the CAOCs 
supporting 4ATAF (southern Germany), 7AF (Korea) and the CONUS-based numbered air 
forces (8AF, 9AF, and 12AF). 

It seems clear that the Air Force needs to implement a CAOC “baseline” that provides a 
significant level of standardization while providing some flexibility for unique theater 
operational needs. Standardized CAOC processes would allow a far more efficient cross-flow of 
trained people, provide rapid absorption of augmentation personnel, and set the framework for 
other management actions to further improve the overall conduct of Air Force C 2 . A 
standardized CAOC would also improve the worldwide applicability of the CAOC training 
provided by the C 2 Training and Innovation Group (C 2 TIG) at Hurlburt Field. 

The C 2 TIG has led the development of a detailed hierarchy of publications for use by fielded 
CAOCs and training organizations. However, the majority of these documents remain in draft 
form. 


Table 2-1. AOC Related Publications 


Title 

Date 

Status 

Air Force C 2 CONOPS 

24 Mar 1999 

Signed 

Enroute Operations Center (EOC) CONOPS 

30 Jun 2000 

Draft 

Space Operations Center CONOPS 

15 Marl 999 

Signed 

C 2 ISR CONOPS 

24 Jul 2000 

Draft 

Battle Control System CONOPS 

4 Nov 1999 

Draft 

Time-Critical Targeting (TCT) CONOPS 

8 July 1997 

Signed 

Air Force AOC CONOPS 

19 Apr 2000 

Draft 

AFI 13-1 Vol. 1 (AOC Training) 

16 Jan 1997 

Draft 

AFI 13-1 Vol. Ill (AOC Operations Procedures) 

6 Mar 2000 

Draft 

EAF C 2 Reference Book 

27 Jan 2000 

Approved for use 

AOC Process Manual 

1 July 2000 

Draft 

Blue Order of Battle CONOPS 

12 Aug 2000 

Draft 


The SAB supports the work being done by the C 2 TIG at Hurlburt Field. A multi-command AOC 
baseline group exists, draft AOC baseline publications have been written and it appears that the 
Air Force is moving toward a standardized CAOC/AOC organization. These efforts have also 
been sensitive to retaining limited flexibility for theater-specific uniqueness. In addition, the 
AC2ISRC and the C 2 TIG have produced significant numbers of CONOPS, AFIs, and TTP 
manuals. It was the opinion of the SAB that sufficient CONOPS exist to guide development of 
the CAOC; however, more work is needed in many areas on training publications. While the 
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CAOC/AOC baseline project is not a full solution for CAOC standardization, it does set the 
stage for the follow-on, detailed work required to standardize all Air Force CAOCs. 

2.6.4 Improve Theater C 2 Training 

The Air Force proudly points to its core competencies because of their uniqueness to the Air 
Force and the superior way in which they are accomplished. Highly effective training is the 
main reason for the Air Force’s superior execution of its core competencies. Such is not the case 
with Air Force theater C 2 operations from the unit level to the JFACC. The Air Force does not 
provide the same quality of training for theater C as for its core competencies. Improving the 
quality of theater C 2 training will provide an exponential improvement in aerospace operations 
efficiency and capability. 

Growing C warriors and leaders who understand the art and science of the application of 
aerospace power is the foundation for eliminating the pick-up team process now used to support 
a wartime contingency. Realistic daily C training, high-quality people, and connected C 
systems will significantly improve theater C 2 capabilities. 

Achieving this objective will require theater C 2 training that is integrated with the peacetime 
flying training and is done routinely during the 5-day workweek. Integrating AOC training with 
other theater control centers and real-world flying training will improve the quality of theater C 2 
training and standardization. Today’s theater C 2 system also needs to have an effective 
certification process for AOC operators and inspections to ensure compliance with AFIs. 
Establishing realistic and regular training, standardization and inspection will greatly improve 
the Expeditionary Air Force’s ability to make a smooth transition from peacetime to wartime 
operations. 

Recommendations 

Establish a career track for C 2 warriors (AF/XO and AF/DP) 

Improve JFACC and CAOC training from the Numbered Air Force down to the wings and air 
control centers (AF/XO and AF/DP) 

Improve cross-MAJCOM C 2 training for support of the EAF (AF/XO and AF/DP 
Improve Joint and coalition C 2 training (AF/XO and AF/DP) 

2.6.5 CAOC/AOC Training Issues 

Air Force CAOC/AOC training programs have lagged in definition and rigor when compared to 
other weapons systems. This results in a pick-up team approach for CAOC operations in both 
exercises and in real-world contingencies—a major operational problem. 

A brief review of the history of formal CAOC/AOC training may help frame the overall issue as 
it exists today. The Air Force created the Blue Flag program in the late 1970s with the objective 
of providing AOC training. The initial goal was to train potential AOC augmentees in theater- 
specific processes and procedures. Typically, Blue Flag would plan an exercise such as Korea by 
visiting the theater well in advance of the exercise date. The visit focused on identifying current 
theater procedures, updating the Blue Flag library with the theater documents, and identifying 
selected theater personnel to come to the exercise and act as advisors. The Blue Flag AOC was 
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configured to replicate the theater-specific facility. This approach provided a reasonably high 
degree of fidelity with regard to each theater’s AOC processes. In the late 1980s, both 9AF and 
12AF began using Blue Flag as a training vehicle and helped develop the warfighting scenarios. 
The numbered air force (NAF) staffs relocated to Hurlburt once a year for Blue Flag training 
which was focused and received very high marks from Gen Homer after his Desert Storm 
experience. 

While Blue Flag continues to provide valuable training, there is no effective mechanism to 
identify, train and track people who have been trained in theater-specific processes and 
procedures for CAOC operations. 

A second issue is the manner in which CAOC/AOC training is conducted. The requirements for 
AOC training are defined in AFI 13-1, Vol. 3. This document provides a well-recognized 
training construct of initial qualification training, mission qualification training (MQT), and 
continuation training (CT); however, continuity of this construct falls apart during 
implementation. The MQT program is implemented as a local unit-training program and may 
not provide the trainee a realistic picture of the dynamic CAOC environment. CT is also 
conducted at the unit level with occasional opportunities to work in a CAOC exercise, such as a 
Blue Flag, Ulchi Focus Lens, or similar Joint-level exercises. The SAB concluded that current 
training falls far short of what is needed and that training is not consistent with the Air Force’s 
belief that we must “train the way we fight.” The CAOC Weapons System is complex and needs 
to be “flown” regularly—not once or twice a year. Theater Battle Management Core System 
(TBMCS), the primary software system for the CAOC, is extremely capable, but complex. No 
one individual understands its full capability. Just as Air Force operators must fly complex 
aircraft frequently and regularly to maintain proficiency, C 2 warriors must operate the complex 
CAOC weapon system frequently and regularly to maintain proficiency. 

Recommendations 

Initiate an effective and reliable system to track CAOC-trainedpersonnel (AF/DP) 

Identify specific CAOC-trained personnel to fill in as augmentees for unmanned CAOC “spaces” 
during contingencies (AF/XO) 

Task frequent 12/5 CAOC operations for Continuation Training (AF/XO) 

Evaluate the effectiveness, style, and size of CAOC training programs-explore distance learning 
(AF/XO) 

Manage the CAOC as a Weapon System (AF/XO) 

• Train CAOC personnel “the way we fight” 

• Develop a Designed Operational Capability Statement 

• Establish standards of performance and an effective training, standardization evaluation, 
and inspection program 

• Conduct joint training—both live and virtual 

• Conduct Operational Readiness Inspections 
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2.6.6 CAOC/AOC Manning Issues 

Air Force-provided AOCs are not fully manned, and there is no reason to expect this situation to 
improve. The problem is further exacerbated by the lack of C 2 Warrior School slots and the 
limited number of Blue Flag training opportunities. This lack of quality training opportunities 
keeps AOC operational proficiency low. The Air Force also has not operationally tested and 
validated its AOC Unit Manning Documents. 

The number of people required for the AOC Quick Response Package (QRP), Limited Response 
Package (LRP), and Theater Response Package (TRP) has never been operationally tested and 
verified. However, the Air Force has recently proposed a new Unit Type Code (UTC) 
composition for the QRP, but the package has not, at this time, been operationally tested and 
verified. Table 2-2 analyzes potential AOC manning reductions based on the fielding of 
operationally significant new technology (TBMCS) and implementation of an effective AOC 
training program. 


Table 2-2. Potential Reductions in AOC Manning 
AOC/AFFOR 


Sorties/day 

Size 

Today 

2001 

2005 

300-900 

QRP 

441 

350 

250 

900-1,800 

LRP 

870 

600 

400-500 

1,800-3,000 

TRP 

1,055/146 

800/99 

600-700/80 


(Note: QRP and LRP do not include AFOR manning) 


The SAB also believes that the number of Air Force AOCs must be reduced in order to fix the 
AOC manning and training problem. Today AOC-assigned manpower is about 30 percent less 
than authorized, a situation that is not expected to improve in the near term. Furthermore, there 
are not enough school slots available at the Hurlburt C Warrior School to sustain the AOC crew 
force, and Blue Flag training opportunities for the AOC Weapon System are limited. The 
current manning situation, together with the lack of quality training opportunities, severely 
impacts AOC operational readiness. Therefore, to improve AOC readiness, the board 
recommends a reduction in the total number of Air Force AOCs to five and the realignment of 
existing manpower as shown in Table 2-3. This reduction in AOCs will allow the remaining 
AOCs to be fully manned and fix the 30 percent less than authorized situation of the NAFs 
today. The Combat Air Forces NAFs, without AOCs, could become Regional Engagement 
Headquarters. 
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Table 2-3. CAOC/AOC Manning Proposal 


Numbered 
Air Force 

NAF/AFFOR 

Manning 

AOC 

Peacetime 

Manning 

AOC 

Wartime 

Manning 

ARF UTC 
Manning 

Active UTC 
Manning 

Area of Operations 

7AF 

99 

QRP/350 

TRP/800 

250 

200 

U.S. Forces Korea 

8AF 

99 

QRP/350 

LRP/600 

125 

125 

Pacific Command 

9AF 

99 

LRP/600 

TRP/800 

200 


Central Command 

12AF 

99 

LRP/600 

TRP/800 

200 


Southern Command, 
European Command 
(EUCOM)-Africa 

16AF 

99 

QRP/350 

LRP/600 

125 

125 

EUCOM 

Regional 

Engagement 

NAF 







3AF 

99 






5AF 

99 






11AF 

99 






13AF 

99 






Total 

891 

2250 

3600 

900 

450 



The above number of AOCs is notional; however, three fundamental AOC requirements must be 
met when determining the number of AOCs that the Air Force can support: (1) The Air Force 
should ensure that all AOC Weapon System authorized manpower positions are filled and that 
this staff is fully trained in peacetime. They will provide a highly effective initial AOC combat 
capability until the augmentation forces arrive. (2) The Air Force Reserve and Guard should 
provide at least one-third of the wartime augmentees. They have provided high-quality, trained 
forces for theater AOCs. (3) If additional augmentees are required, they should be sourced from 
one of the other four fully trained AOC staffs. Following the above recommendations will fix 
most of our current AOC pick-up team deficiencies. SAB also believes that 8AF should be 
authorized a QRP so that they can train with an AOC staff and not become another “behind the 
Green Door” information operations organization. This would also allow 8AF to use 
collaborative tools to support other NAFs’ peacetime training requirements. 

Recommendations 

Operationally test and validate the AOC UTCs based on a fully trained AOC staff and 
operationally effective technology (TBMCS) 

Reduce the number of Air Force-provided AOCs to five and fully man this C 2 Weapon System 
(CSAF) 

2.6.7 Time-Critical Targeting (TCT) 

TCT will require a change in how the Air Force thinks about C 2 . It will impact theater C 2 
architecture design, modernization, and training. Although the TCT target set may be small or 
non-existent during the initial phase of an air campaign and overall is a fraction of total C 2 
activity, TCT needs will push operational process improvement, pull technologies, and drive C 2 
efficiency. An effective TCT capability will require superior coordination and C 2 of sensors 
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2 

operating in air, ground, and space and simple intuitive tools for C warriors to effectively find, 
fix, target, track, engage, and assess any target in the BattleSpace. Building an effective TCT 
capability can be the operational imperative that breaks down the organizational, technology, and 
process stovepipes that constrain C 2 effectiveness today. Aircraft weapon systems and munitions 
are designed and built to meet the most demanding missions. TCT, the military’s most 
demanding C 2 mission, can and should be the driving force behind Air Force theater C 2 and ISR 
modernization and development. Developing a highly effective TCT capability will address 
most theater C 2 mission deficiencies that exist today. These capabilities include automated: 
intelligence preparation of the battlefield (IPB) development, effects-based targeting, and effects- 
based combat assessment. Other enhancements required include quality COP, enhanced 
information operations/ISR control cell, integrated database, Web-enabled and enhanced 
communications. 

If C 2 warriors are able to successfully direct TCT engagements, C 2 in other theater mission areas 
will also significantly improve. The AC2ISRC’s TCT analysis in its Family of Systems 
Requirements Document, 11 January 2000, and Strategy and Modernization Plan for Time 
Critical Targeting and Real Time Information to the Cockpit, 7 February 2000 (approved by the 
Air Force Requirements Oversight Council) is extensive and addresses the key end-to-end 
organization, process, and technology issues for fixing TCT. This analysis offers the Air Force a 
“silver thread” that can be used as the foundation for the joint and multi-Service theater C 2 
system modernization. 

Recommendations 

Accelerate the multi-service and joint staffing of the Defeating Theater Time Critical Targets 
requirements document (AF/XO) 

Develop and fund a TCT science and technology research and development program (SAF/AQ 
andAF/XP) 

Fund and implement an effective TCT spiral development program (SAF/AQ, AF/XP, and 
AF/XO) 

Fund and quickly transition operationally significant TCT technologies and TTPs to the field 
(SAF/AQ, AF/XO, and AF/XP) 

2.6.8 Develop and Field the Battle Control Center (BCC) 

The BCC concept will provide a modernized decentralized C 2 execution node for the Air 
Component Commander and CAOC. It should be organized to direct air battle execution, 
theater air defense, data link management, combat identification, and surveillance. The BCC 
should provide the Air Component Commander and JFC with a near-real time means of 
managing a single integrated air picture from air-, sea-, land-, and space-based sensors. Not only 
should the BCC provide the Air Component Commander with the personnel, TTPs, and 
equipment necessary to direct and control theater air operations, but the BCC should be equipped 
and trained to conduct limited theater planning, coordinate air operations with other joint and 
combined forces, and directly augment the Air Component Commander’s airspace control and 
area air defense commander functions. When equipped and trained as described, the BCC can 
serve as a backup to the CAOC. 
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Recommendations 


Accelerate modernization of the TACCS to ensure development and fielding of the BCC (initial 
operating capability [IOC] not later than 2005) (AF/XP, AF/XO, and SAF/AQ) 

Manage the BCC as a weapon system (AF/XO) 

2.6.9 Ensure Joint Interoperability 

No single Service has the C , sensors, and weapons systems to accomplish all DoD missions. 
Therefore, each Service must be able to leverage another Service’s situational awareness and 
weapons systems capabilities. Dynamic retasking of aircraft in support of commanders’ 
priorities will require rapid access to appropriate databases to obtain the near-real time 
information that is essential for dynamic decision making. Joint interoperability also requires 
Air Force C 2 systems that are interoperable with GCCS and other service C 2 systems. 
Interoperable databases and appropriate data links are the foundation of this capability. The 
following initiatives are needed for the joint interoperability of the future TACCS: 

1. Develop and refine the Joint COP: Air Force and Army information systems cannot now 
rapidly exchange data in support of dynamic retasking. There is a need to resolve 
interoperability issues between TBMCS and the Army Battle Control System (ABCS). 
Furthermore, there is a need to develop joint TTPs that outline how all service sensors 
support the near-real time COP and targeting. 

2. Develop procedures for cross-cueing of Service ISR assets: ISR assets currently work as 
stove piped systems, but target attack often requires cross-cueing of other ISR assets to verify 
and/or refine information. New procedures are needed to cross-cue sensors and, if required, 
provide continuous target coverage until the mission is completed. For example, the AOC 
should have data links to the Corps’ Deep Operations Coordination Cell (DOCC) to 
nominate targets for Army ISR asset coverage. Likewise, the DOCC should be able to 
nominate targets for Air Force ISR asset coverage. 

3. Refine ATO procedures: While the Air Force, Navy, and Marine Corps all control aircraft 
by tail number, the Army controls helicopters by units as a subset of the combined arms team 
near the forward line of troops (FLOT) or when attacking targets beyond the FLOT. The 72- 
hour ATO process appears to be too restrictive to accommodate helicopter missions that are 
responding to the ground commander taskings. However, helicopters need to be included in 
the ATO process to prevent fratricide and coordinate Suppression of Enemy Air Defenses 
(SEAD) and Combat Search and Rescue (CSAR). Interoperable information systems should 
permit the addition of helicopters to the ATO on relatively short notice. For example, the 
DOCC could provide placeholders 30-plus hours in advance and wait until the last possible 
time (for example, 6 hours) to provide specifics. We recommend that procedures be 
developed between TBMCS and the Advanced Field Artillery Tactical Data System 
(AFATDS) to accomplish the short-notice inclusion of helicopters in the ATO. 

4. Complete the development of TBMCS—AFATDS interoperability: AFATDS-TBMCS 
interoperability is essential for integrating battle plans and coordinating situational 
awareness. The effective exchange of information between the AOC and DOCC will rapidly 
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improve joint target-weapon pairing capability. The DOCC can also quickly receive the 
ATO and ATO updates from the AOC and pass Candidate Targeting Lists to the AOC. 

5. Ensure TBMCS can access the Army’s All Source Analysis System (AS AS) data: AS AS 
can contribute to the air COP by providing information for IPB, situational awareness, and 
near-real time retasking of strike aircraft. Interoperability gateways will permit passing of 
tactical electronic intelligence reports and other tactical reports, as well as interactive 
TBMCS-ASAS databases. 

6. Improve air-ground operations situational awareness: CAS must have situational 
awareness on the location of friendly ground forces to prevent fratricide and improve support 
to the ground force commander. The Army and Air Force should establish a gateway 
between the Army’s Enhanced Position Location Reporting System Enhanced Position 
Location Reporting System (EPLRSj/Virtual Message Format (YMF) ground network and 
the Joint Data Network so that CAS aircraft have accurate locations of friendly ground 
forces. The Army should also be encouraged to modify its VMF message formats to include 
altitude and height information. This would result in a more accurate location of ground 
forces for CAS aircraft. 

7. Refine joint airspace clearance procedures: There appears to be a need to clarify the 
Army Tactical Missile System (ATACMS) immediate and preplanned fires procedures 
within Joint Doctrine. 

8. Improve mission planning, rehearsals, and retasking: JFCs lack the ability to conduct 
real-time mission planning before redirection of strike aircraft. The Rome Laboratory’s 
Information for Global Reach program may allow ground commanders to conduct 
collaborative planning with air commanders while missions are en route to the theater of 
operations. 

9. Place more emphasis on joint training: We recommend that the numbered air forces and 
land components and corps participate in peacetime ATO development. AOCs should also 
participate in Army Corps Warfighter Exercises. 

Recommendations 

Refine air-ground operation procedures and ensure interoperability of C 2 systems. 

• Ensure that TBMCS and ABCS are interoperable (AF/XO) 

• Develop operating procedures for the AOC to request sensor support from Army ISR assets and 
for the DOCC to request sensor support from AOC ISR assets (AF/XO) 

• Refine ATO procedures to allow reduced timelines for inclusion of Army helicopters in the ATO 
process for SEAD and CSAR support. Consider using AFATDS connectivity to TBMCS to 
expedite the process. (AF/XO) 

• Complete the development of gateways between TBMCS and AFATDS (SAF/AQ) 

• Establish a gateway between EPLRS/VMF and the Joint Data Network to provide CAS aircraft 
with accurate locations offriendly ground forces (SAF/AQ) 

• Refine joint airspace clearance procedures to include ATACMS immediate and preplanned fires 
within Joint Doctrine. Consider the TBMCS-AFATDS and the TBMCS-Tactical Airspace 
Integration System linkages as a means to expedite clearances. (AF/XO) 
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• Place more emphasis on joint training to include AOCparticipation in all Army Corps 
Warfighter Exercises (AF/XO) 

Interoperability issues are explored in detail in the Report of the Interoperability Panel, 

Chapter 3. 

2.6.10 Air Force Forces 

Operations from World War II to the present continue to point to a lack of progress in defining, 
organizing, and institutionalizing a theater-smart highly trained AFFOR capability. More 
attention is needed for the maturation and development of the AFFOR organizational concept, 
staffing, C training and exercises, decision support systems, processes, and UTCs. 

Senior leadership must define the AFFOR organization and develop a distributed operations 
concept using forward elements and reachback locations. The AFFOR staff is an operational Air 
Force wartime capability and must be established and ready to execute its mission in direct 
support of deployed theater aerospace forces. However, the Air Force has often used existing 
resources and a pick-up team when an operation commences. AFFOR staff must be assigned to 
an AFFOR UTC and receive effective training to carry out their mission. Manning for AFFOR 
UTCs should be sourced from previously identified and trained personnel from the engaged NAF 
staff, non-engaged NAF staffs, and MAJCOM staffs. These individuals must train regularly to 
perform AFFOR functions. Commanders may tailor and position AFFOR C 2 centers to support 
contingencies. 

AFFOR functions and responsibilities are not well defined, understood or implemented: 

The corporate Air Force needs to educate airmen on the difference between the Service C 2 
functions of the AFFOR staff (HQ) and the “operational” C 2 element, the J/CAOC. 

COM AFFOR requires a capable staff to plan, deploy, employ, sustain, and redeploy aerospace 
forces to carry out the JFC’s mission objectives. This is an enduring requirement for deployed 
aerospace forces and is separate from the responsibilities of a dual-hatted COM AFFOR’s 
JFACC. 

AFFOR functions should be well defined: NAF staffs have competing missions in supporting 
both their J/CAOC and the AFFOR responsibilities. The current Air Force structure and 
CONOPS assume that NAFs provide the staff for an AFFOR forward capability. The NAFs are 
not staffed or trained to carry out the AFFOR role. 

The Air Force must decide how to transition AFFOR support from peacetime to wartime, the 
organization responsible to staff the AFFOR, and AFFOR functions that can be deployed 
forward. All other AFFOR functions should be performed in the rear. The concept for 
Operational Support Centers (OSC) is sound for reachback support. 

AFFOR documentation and guidance are lacking: An agreed-upon AFFOR “roadmap” does 
not exist. Over the past 2 years, the AC2ISRC has led an AFFOR baseline effort. Many 
documents were written. To date, the UTCs are registered, but no unit is responsible for 
implementing the UTCs and Air Force approval of the AFFOR CONOPS, operational guidance, 
and training has not been achieved. 

AFFOR organizations, systems, processes, and allocation of manpower must be defined before 
training programs are built. The AFFOR baseline team started from scratch and developed a 
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CONOPS and an AFI for operational guidance; TTPs are in development. Once staffed and 
approved, development of executable AFFOR UTCs and identification of AFFOR training needs 
will follow. 

General officer ownership and guidance: Air Force leadership must identify an advocate to 
define AFFOR mission requirements and capabilities. Air campaign success is depends on 
having the right support, at the right time, in the right place. The AFFOR provides this support. 
As such, AFFOR is a capability the Air Force needs to support, develop, and institutionalize. 

Recommendations 

Identify an Air Staff advocate for AFFOR C 2 requirements and capabilities (CSAF) 

• Define and fully implement the AFFOR organizational concept described above (CSAF) 

• Identify and train AFFOR staff members; NAFs, MAJCOMs, and/or in-place OSCs 
(AF/XO and AF/IL) 

• Identify AFFOR/AOC functional relationships (AF/XO and AF/IL) 

• Develop, staff and approve CONOPS, AFI (Vol. 1 and III), TTPs, executable UTCs, and logistics 
detail (AF/XO and AF/IL) 

• Determine requirements and implement regular training exercises for AFFOR staffs 
(AF/XO and AF/IL) 

Further define the forward/reachback concept for AFFOR operations (AF/XO and AF/IL) 

2.7 GCCS-AF 

To date, the Air Force has produced stove piped legacy C systems across numerous mission 
areas such as mobility, space, strategic, ISR planning and weapons control, mission planning, 
theater battle management, and agile combat support. Separate acquisition and support efforts 
have led to duplicative information views across mission areas and different computing 
infrastructures. These stove-piped C 2 systems have limited interoperability. This results in 
multiple C 2 systems within C 2 centers that provide inconsistent information views and produce 
complex technology environments for the operator. 

Most of the stove-piped C systems can be attributed to multiple C management structures, 
limited cross-flow of requirements, and lack of a consolidated C 2 ISR enterprise-wide view of C 2 . 
These separate management processes have resulted in stove-piped system production, 
duplication across mission areas, questionable use of resources (funding, manpower), and 
fragmented information to the warfighter. The separate processes that manage Air Force joint 
requirements for GCCS and TBMCS are an example of multiple C 2 management structures. 

2.7.1 Defining GCCS-AF 

GCCS-AF should be thought of as the Air Force’s implementation of the Joint GCCS program, 
and it should be used to manage and define the automated C 2 and ISR mission tools for Air Force 
strategic, theater, wing, and unit commanders. 

Merging C 2 and ISR weapons system applications into a single GCCS-AF C 2 system will 
provide the warfighter with a common integrated and interoperable family of C 2 applications that 
can display common information on common hardware. GCCS-AF should be linked by the 
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global information grid and enable collaboration with all warfighters, including the CINCs and 
other Services. 

2.7.2 Implementing GCCS-AF 

2 2 

Movement to a single Air Force C system in GCCS-AF and establishment of a single C 

management oversight structure are critical to the Air Force’s C 2 enterprise. Several systems 
must be folded into GCCS-AF in the near term and become part of the JBI as it evolves. 

Figure 2-7 depicts how existing systems need to be integrated into GCCS-AF. 
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Figure 2-7. GCCS-AF 


There also needs to be an Air Force policy decision that directs GCCS-AF. The integration of all 
future Air Force unit- and force-level applications (for example, mission planning, crisis 
planning, space battle management, and mobility planning and execution applications on the 
GCCS-AF software and hardware infrastructures) should be clearly stated in the policy directive. 
This will produce an integrated C system across Air Force C domains and link the Air Force by 
2005. 

The near-term technical strategy for an integrated GCCS-AF should include migration to the 
joint GCCS common integration framework—the Defense Information Infrastructure Common 
Operating Environment (DII COE) Level 6. This should continue for the short term; however, 
the mid- to long-term solution is a Web-based integration framework, which, in turn, will enable 
the development of a full JBI capability. This concept was described in the SAB’s December 
1998 Study, Information Management and December 1999 Study, Building the Joint Battlespace 
InfoSphere. 

Recommendations 

Designate GCCS-AF as the Air Force C 2 system (CSAF) 

• Develop and expedite transition planning to consolidate CJSR mission functions into GCCS-AF 
(SAF/AQ) 

• Establish a single management oversight process to represent the Air Force in joint GCCS 
management (AF/XO) 
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• Establish a C 2 integration program that is empowered to integrate activities between the various 
C 2 centers and nodes (SAF/AQ) 

2.8 Migrating to the Joint Battlespace InfoSphere 

JBI is a proposed improvement for C 2 that recognizes and exploits the design and development 
processes that have been sweeping across the commercial information technology markets. It 
represents a major evolutionary milestone in information system design and offers operational, 
system, and technical improvements. Currently there is no Air Force program that provides for 
developing, acquiring, or fielding the JBI. The Air Force needs to establish a JBI program, and it 
is our recommendation that it be an infrastructure element of the GCCS-AF and Global Combat 
Support System-Air Force programs. Resolving the technical issues involved with migrating 
from today’s GCCS DII-COE design construct to the JBI design construct will require that it be 
closely linked to the GCCS program. Close cooperation with Defense Information Systems 
Agency (DISA) and DII COE governing bodies will also be required. 

Figure 2-8 depicts the progression in software design styles. Previously, C 2 systems were built 
using modular software in which the system comprised software code that was easily 
distinguished as separate software modules. Recently, a more sophisticated modular software 
approach has been used in which the applications code is distinguished from the infrastructure 
code. This infrastructure code provides services required by C 2 applications that ride on the 
code; the infrastructure code is built using common commercial sources. The DISA DII COE is 
an example of this infrastructure code that is used for C 2 systems development today. 
Interoperability among C 2 systems was thought to be easier if systems used a common 
infrastructure. However, it is becoming widely accepted that a common DII COE infrastructure 
is insufficient for achieving interoperability. Common data semantics, or a means for converting 
different data structures, is also needed. We also believe that the burden of maintaining common 
versions of DII COE across different C 2 and ISR systems is considerably more demanding than 
maintaining common Web-based protocols for information exchange. This increasing cost for 
maintaining the DII COE will motivate the development of the JBI. 
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Figure 2-8. Contrasting Styles of Design 


2 

The JBI enables interoperability without requiring the same version of DII COE across all C 
systems. As a result, development of the JBI is becoming a more attractive means for achieving 
interoperability. The prime technical mechanism that allows systems to participate in the JBI is 
the adoption of a Web-enabled information exchange process. Today’s web technology entails 
publishing information using Extensible Markup Language (XML) and using subscriptions or 
queries to retrieve the information. Existing systems will be able to migrate relatively quickly to 
the JBI by adopting the XML approach. Future systems will be able to bypass portions of the 
process described above by having capability modules connect directly to the JBI. As more and 
more systems adopt the Web-enabled structure as an internal software construct, the size of add¬ 
on systems will diminish because the JBI’s individual functionality applications, “fuselets,” will 
offer a flexible, easily integrated, and easily upgraded and maintained capability that will replace 
the older add-on systems. In other words, application modules from existing systems can be 
migrated over time from residence within a DII COE infrastructure design towards residence 
within an InfoSphere design. The exchange of information among modules or systems will be 
easier to manage when those exchanges are accomplished through Web-enabled interfaces, 
rather than through adherence to common (that is, the same) components. 

It should be specifically pointed out that adherence to a DII COE configuration is good from an 
integrated product standpoint. For example, within an application, the use of standard elements, 
standard interfaces, standard protocols, etc., is good practices and should not be abandoned. The 
SAB suggests that it is not necessary for all C 2 systems to use the same version of the DII COE 
and is not recommending abandonment of the DII COE altogether. Different versions are OK 
when using the JBI strategy to satisfy the interoperability objective. However, it is also 
important to adhere to good software engineering practices and use a layered architecture and 
standard components, such as can be found in individual versions of the DII COE, to develop 
individual system or application modules. 
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We recommend that this JBI migration be funded by one PE and be managed by a single System 
Program Office (SPO) that is devoted to fielding Air Force enterprise-wide interoperable C 2 . 
Thus it makes sense to consider consolidating existing programs, such as the TBMCS, along 
with infrastructure evolution programs, such as GCCS-AF, into a single office that is devoted to 
the growth and fielding of the JBI. 

Recommendations 

Develop a long-term JBI strategy and fund it. 

• Use an internet or Web-based implementation strategy (AF/XO and SAF/AQ) 

• Use the Web and related technologies (such as XML) emerging from the commercial world for 
JBI development (SAF/AQ) 

• Require an open system design for JBI development (SAF/AQ) 

Establish a SPO that is responsible for fielding Air Force enterprise-wide interoperable C 2 
(SAF/AQ) 

2.9 Summary 

The Air Force vision of “well-equipped C centers collaborating globally in support of the 
CINCs” can be rapidly achieved if senior Air Force leadership strongly endorses the need for an 
enterprise-wide C 2 capability. The Air Force must restructure the way C 2 programs are managed 
and resourced, and leadership must clearly speak out about their dedication to achieving an 
enterprise-wide C 2 capability at every opportunity. In this chapter we have defined the current 
C 2 system and provided a proposal for how the Air Force can achieve an enterprise-wide C 2 
capability by 2005. We have provided our views on areas that the SAF, Air Staff, and 
MAJCOM staffs should focus on in starting down a C 2 modernization journey. The journey of 
achieving an effective distributed, collaborative, enterprise-wide C 2 capability that allows C 2 
centers to collaborate globally in support of the CINCs is one of the most important journeys the 
Air Force needs to take in the 21 st century. 

Reference Appendix 2A through 2C for the C 2 System Definition and Operational Concept 
Panel’s Charter, membership, and fact-finding visit schedule. 
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Appendix 2A 

C 2 System Definition and Operational Concept Panel Charter 


Serve as the focal point of the study for the description and review of 

• The current command and control concepts and procedures 

• The current C 4 ISR systems and their supporting infrastructure 

Define the needed future capability for command and control (circa 2005) and develop a set of 
recommendations on how the Air Force can achieve these capabilities. This includes changes in 
the existing systems or ongoing programs through the introduction of new technology (as 
defined by the Technology Panel) and changes in training and personnel policies (as articulated 
by the People and Organization Panel). Such changes may require enhancements of the 
acquisition process (as addressed by the Acquisition and Program Management Panel). 

Examine the command and control process both from the corporate Air Force level and from the 
operational level, particularly in joint and combined operations. 

Address the following points 

• Identify the Air Force concepts of operations for C 2 

• Identify the current C 2 elements and planned improvements that will have an impact on 
operations by 2005 

• Identify the missions the Air Force is expected to carry out in this timeframe 

• Identify the changes in the planning-execution-assessment cycle 

Recommendations for the short-term improvements should be consistent with the Air Force’s 
long-term command and control goals. 
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Appendix 2B 

C 2 Concept and System Definition Panel Membership 

Lt Gen Joseph E. Hurd, IJSAF (Ret), Chair 
Private Consultant 

Maj Gen John A. Corder, USAF (Ret) 

Private Consultant 

Mr. Troy Crites 
Sparta, Inc. 

Dr. Llewellyn S. Dougherty 
Director of Technology 
Raytheon Electronic Systems 

Mr. Jim Hale 
Private Consultant 

Maj Gen John Hawley, USAF (Ret) 

Private Consultant 

David Hess 

AC2ISRC 

MITRE 

Col Stu Kraft, USAF (Ret) 

Director, Business Development 

Northrop Grumman/Logicon Technical Solutions 

Maj Robert Lanahan 

Branch Chief, Future Communications Systems 
National Reconnaissance Office 

Prof. Alexander H. Levis 
Professor 

George Mason University 

Prof. Christine Mitchell 

Professor 

Georgia Tech 

Maj Robin Morris 
AC2ISRC/C2A 
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Col Wayne Ranne, USAF (Ret) 

Private Consultant 

Col Mike Reavey, USAF (Ret) 

Private Consultant 

Mr. Skip Saunders 
Executive Director 
MITRE 

Prof. Gene Spafford 
Professor 
Purdue University 

Col Carl Van Pelt, USAF (Ret) 

Private Consultant 

Lt Gen Ronald Watts, USA (Ret) 

President 

Leadership Development Services 

Executive Officer: Capt Larry W. Norman, Jr., AC2ISRC/C2RO 
Technical Writer: Maj Thomas Schorsch, USAFA 
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Appendix 2C 

C 2 Concept and System Definition Panel Visits 

Hurlburt AFB, C 2 TIG, 3-4 May 00 

Langley AFB, Air Combat Command, 11-13 April 00 

Nellis AFB, Spring Board Meeting, 25-27 April 00 

Las Vegas, Agile Combat Support Conference, May 00 

Boeing, Seattle, WA, 29-30 June 00 

Davis Monthan AFB, 7-9 June 00 

National Reconnaissance Office, Capability and Interoperability, 16-17 May 00 
Defense Advanced Research Projects Agency, Capabilities, 18 May 00 
Rome Research Site, Capabilities, 12 June 00 
Hanscom AFB, Programs Review, 13-14 June 00 
San Diego, C 2 on Coronado, 17 July 00 

SAB Summer Session, San Jose, CA, Final Report, 10-21 July 00 
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Appendix 2D 

C 2 Weapons System Management—“Matrix Table” 



CONOPs 

ORD 

Program 

Element 

PMD 

Acguisition 
Program Manager 

Panel 

MAP/ MSP 

C4ISP 

C2 Weapon System 









AOC 

TACCS/AOC 

TACCS 

AOC 

TACCS/AOC 

CAF C2 

C4I 

TACCS MAP 

AOC 

AFSPACE AOC 

AFSPACE AOC 

AFSPACE AOC 

AFSPACE AOC 

AFSPACE AOC 

Space & Nuc Det 

C4I 

Space C2 

AFSPACE 

AOC 

ASOC 

TACCS/ASOC 

TACCS 

TACCS 

TACCS/ASOC 

CAF C2 

C4I 

TACCS MAP 

ASOC 

BCC (CRC/CRE) 

TACCS/BCC 

TACCS 

TACCS 

TACCS/BCC 

CAF C2 

C4I 

TACCS MAP 

BCC 

TACP 

TACCS/TACP 

TACCS 

TACCS 

TACCS/TACP 

CAF C2 

C4I 

TACCS MAP 

TACP 

Airborne FAC 

TACCS/FAC 

TACCS 

TACCS 

TACCS/FAC 

CAF C2 

C4I 

TACCS MAP 

FAC 

TACC 

Mobility C2 

Mobility C2 

Mobility C2 

Mobility C2 

Mobility C2 

C4I 

Mobility C2 MAP 

TACC 

OSC (3) (AFFOR) 

TACCS / OSC 
(AFFOR) 

OSC (AFFOR) 

OSC (AFFOR) 

TACCS/ 
OSC(AFFOR) 

OSC (AFFOR) 

C4I 

TACCS MAP & 

ACS MSP 

OSC 

(AFFOR) 

AFIWC 

AFIWC 

AFIWC 

AFIWC 

AFIWC 

IW 

C4I 

IW MAP 

AFIWC 

ABCCC 

TACCS/FAC 

ABCCC 

ABCCC 

TACCS/ABCCC 

CAF C2 

C4I 

TACCS MAP 

ABCCC 

AWACS Backend 

TACCS/ 

AWACS 

AWACS 

AWACS 

TACCS/ 

AWACS 

AWACS 

Sensor 

TACCS & ISR 

MAPs 

AWACS 

Joint Stars Backend 

TACCS/JS 

Joint Stars 

Joint Stars 

TACCS / Joint 
Stars 

Joint Stars 

Sensor 

TACCS MAP 

Joint Stars 

Rivet Joint Backend 

TACCS/RJ 

Rivet Joint 

Rivet Joint 

TACCS / RJ 

Rivet Joint ? 

Sensor 

TACCS MAP 

Rivet Joint 

USSPACE / NORAD 

Space C2 & 
Homeland 

Defense 

ISC2 / N/UWSS 

ISC2 

ISC2 

Space & Nuc Det 

C4I 

Space C2 MAP 

N/UWSS 

STRATCOM Cmd 
Center 

STRAT C2 

STRAT C2 

STRAT C2 

STRAT C2 

Space & Nuc Det 

C4I 

Strategic C2 MAP 

SWPS 

MCCC 

STRAT C2, 
SPACE C2 & 

Homeland 

Defense 

MCCC 

ISC2 

MCCC 

Space & Nuc Det 

C4I 

Strategic C2 MAP 

MCCC 

NMCC 


NMCC 

NMCC 

NMCC 


C4I 



RAOC/SAOC 

Homeland 

Defense 

RAOC/SAOC 

RAOC/SAOC 

RAOC/SAOC 

CAF C2 

C4I 

Homeland Defense 

MAP 


PED Centers(DCGS, 
UES, etc) 

PED 

PED 

PED 

PED 

GCCS-AF 
Integration (CX) 

C4I 

ISR MAP 

PED 

C4I Applications Sup 

porting the C2 Weapons System 







GCCS-AF 

GCCS-AF 

GCCS-AF 

GCCS-AF 

GCCS-AF 

GCCS-AF 
Integration (CX) 

C4I 

N/A 

GCCS-AF 

GCSS-AF 

GCSS-AF 

GCSS-AF 

GCSS-AF 

GCSS-AF 

GCCS-AF 
Integration (CX) 

C4I 

ACS MSP 

GCSS-AF 

GCCS-AF Weapons 
Control 

GCCS-AF 

Weapons 

Control 

GCCS-AF 

Weapons Control 

GCCS-AF 
Weapons Control 

GCCS-AF 
Weapons Control 

GCCS-AF 
Integration (CX) 

C4I 

TACCS MAP 


C4I Communication t 

i Software Infrastructure Supportin< 

* the C2 Weapons 

»System 





Tactical Comm 

Comm 

Tactical Comm 

Tactical Comm 

Tactical Comm 

Infrastructure 

C4I 

Infrastructure MSP 

multiple 

Base Level Comm 

Comm 

Base Level Comm 

Base Level 

Comm 

Base Level 

Comm 

Infrastructure 

C4I 

Infrastructure MSP 

multiple 

Long Haul Comm 

Comm 

Long Haul Comm 

Long Haul Comm 

Long Haul Comm 

Infrastructure 

C4I 

Infrastructure MSP 

multiple 

SATCOM 

Comm 

SATCOM 

SATCOM 

SATCOM 

Infrastructure 

C4I 

Infrastructure MSP 

SATCOM 

Information Infrastructure & Integration of the C2 Weapons System 






Common Information 
Management (CIM) 

CIM 

CIM 

CIM 

CIM 

GCCS-AF 
Integration (CX) 

C4I 

Common 

Information 
Management MSP 

N/A 

Datalinks 

CIM 

Datalinks 

Datalinks 

Datalinks 

GCCS-AF 
Integration (CX) 

C4I 

Common 

Information 
Management MSP 

N/A 

JNTCCS (Joint) 

CIM 

JNTACCS (Joint) 

JNTACCS 


GCCS-AF 
Integration (CX) 

C4I 

Common 

Information 
Management MSP 

N/A 

AF Sensors providing critical information to the C2 Weapon System 






All Sensors (sapce, 
airborne & ground) 

Sensor 

Sensor 

multiple 

multiple 

multiple 

Sensor 

ISR MAP 

One for 

each 

Sensor 

NOTES: 









There is an Aerospace C2 CRD over all the listed ORDs; these will contain the total list of Interoperabiltiy KPPs (lERs between nodes) 


There is a capstone PMD over all the listed PMDs directing cross program roadmaps to achieve the CRD capabilities 
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Chapter 3 

Report of the Interoperability Panel 


3.1 Introduction 

The future of America’s military success, and thus of its national security and ability to achieve 
national objectives, depends critically on information-enabled operations. 1 Information 
dominance—the ability to employ information to achieve decisive battlespace advantage while 
denying such use to an adversary—is one of the central tenets of joint doctrine, strategy, and 
tactics. Achieving this advantage means that individual Service, joint, and coalition forces must 
be able to gather, share, process, interpret, and use information and do so with superior speed, 
reliability, security, and resistance to enemy actions. As military history has repeatedly shown, 
the side with an information advantage will usually prevail, even against superior numbers. 2 
This is increasingly the case in modem operations and it applies to every level of the spectrum of 
conflict. 

Rapidly advancing technology—from sensors to communications to computers and displays— 
provides much of the foundation for Information Dominance. Yet decades-old problems with 
incompatible equipment, divergent definitions and uses of data, uncoordinated procedures, and 
other aspects of information sharing continue to plague U.S. and allied military forces. We have 
repeatedly found ourselves enjoying an advantage in the sophistication of our technology, only to 
have that advantage reduced or negated by a lack of interoperability. Recognizing the 
seriousness and importance of this problem, this Air Force Scientific Advisory Board (SAB) 
study has devoted a specialized panel to the topic and charged it with determining the sources of 
non-interoperability and the immediate and longer-term steps needed to correct these shortfalls. 

Interoperability means the ability to link the right people and systems, at the right time, in one- 
on-one, one-to-many, or many-to-many situations; and to pass consistent data that converts to 
useful information and thence to actionable knowledge that enables cooperative decision-making 
and resultant action. A bit more formally, the authoritative definition of interoperability is 

1. The ability of systems, units or forces to provide services to and accept services from other 
systems, units, or forces and to use the services so exchanged to enable them to operate 
effectively together. 2. The conditions achieved among communications-electronics systems or 
items of communications-electronics equipment when information or services can be exchanged 
directly and satisfactorily between them and/or their users. 3 

The key words are “operate effectively together.” As we have learned in this study, passing 
messages and data is only the beginning of interoperability, and even the ponderous definition 
just cited only hints at the complexity of the problem of reliably achieving synchronized, 


1 Joint Vision 2020, Chairman, Joint Chiefs of Staff, 2000; Vision 2020: Global Vigilance, Reach and Power, 

General Michael E. Ryan, Chief of Staff, U.S. Air Force, and F. Whitten Peters, Secretary of the Air Force. 

2 As one example, the unauthorized extended absence of Jeb Stuart’s cavalry just prior to the battle of Gettysburg 

deprived Lee of critical intelligence and is considered a major contributor to his defeat. Millennia earlier, Sun 
Szu wrote, “Act after having made assessments. The one who first knows the measures of far and near wins— 
this is the law of armed struggle,”— The Art of War, Thomas Clearly, trans. (Boston: Shambala Publications 
1988). 

3 Joint Publication 1-02, DoD Dictionary of Military and Associated Terms. 
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mutually supportive action among elements of a force. Interoperability has a myriad of facets, 
not only system to system, but also command to command, Service to Service, joint to 
component forces, and joint to coalition partners. Figure 3-1, drawn from the perspective of a 
theater Air Operations Center (AOC), suggests a few of the places where interoperability is 
required. Interoperability requirements escalate dramatically when we look at joint and coalition 
forces and consider connectivity and interoperability among service entities and across warfare 
areas. In combat, the Air Force works in the air superiority, close air support, and ground strike 
warfare regimes and meet air mobility, airspace management, aerial refueling, and other 
requirements. In a joint environment, Air Force units are joined by the Navy in both air 
superiority and ground strike, as well as by the Army and Marine Corps in ground strike. With 
the burgeoning role of naval surface and undersea fire support from off-shore, the Navy’s role in 
ground strike has now extended beyond the functions of Naval Aviation, adding yet another 
variable. When allied forces join the mix, still other disconnects, ranging from equipment 
peculiarities to differences in policy and doctrine, can arise in the interoperability equation of 
joint and coalition warfare. 
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Figure 3-1. Pervasive Needs for Interoperability Throughout a Joint/Coalition Force 


We have proved in recent contingencies that we could get the job done by a joint force without 
an advanced state of interoperability. But we cannot assume that we can continue to do so 
indefinitely, regardless of opponents and scenarios, as the rest of the world closes the gap in 
applying information technology (IT) to warfare. Information dominance will be increasingly 
critical to a Joint Force Commander, and interoperability is a prerequisite. The main focus is on 
mission success, but the incentives for pursuing joint interoperability range from minimizing the 
cost to deploy, operate, and support forces to coping with the political and policy realities of a 
coalition. Thus, while it is reasonable for the Air Force to concentrate efforts on improving the 


3-2 


























interoperability of its own systems and units, there must be an aggressive parallel effort to 
achieve joint and coalition interoperability. At the very least, we must guard against any course 
of action that will further complicate the joint and coalition interoperability problem. 

The Interoperability Panel brought together both senior military officers and technical experts in 
the various disciplines involved. Panel members included retired Air Force and Navy flag 
officers, and we had the benefit of the insight of the Army Science Board participants in the 
study, while the chairman and other panel members are active in interoperability efforts 
involving our allies. We went to great lengths to visit the main organizations working these 
issues in all three Services and to understand their programs and priorities. In the sections that 
follow, we present our analysis of the technical, operational, organizational, and other barriers to 
interoperability and our focused recommendations on how they should be addressed. Inevitably, 
many of our findings and recommendations overlap those of other panels and are reflected in 
their reports as well. 

3.2 Approach and Visits 

The panel charter and membership are given in Appendices 3 A and 3B. The approach taken by 
the panel to address these issues can be summarized as follows: 

• Emphasize contacts with primary organizations in all three Services charged with implementing 
interoperable command, control, communication, computer, and intelligence, surveillance and 
reconnaissance (C 4 ISR) capabilities and the expertise of panel members and other study 
participants with joint and coalition experience 

• Collect data and informed opinion on technical, operational, organizational, doctrinal and 
procedural aspects of interoperability, especially those factors that defy simple solutions through 
standardization and equipment commonality 

• Develop insight into perspectives, goals, and plans affecting interoperability of all Services and 
allied nations 

• Identify key interoperability issues and assign panel members to focus on these; areas include 
information modeling and engineering, system and system-of-systems architectures, data links 
and other communications, human factors and human-machine integration, joint and coalition 
interoperability, interoperability factors in system requirements definition and system acquisition, 
ways to achieve the required central oversight and enforcement of interoperability actions, and 
long-term strategies to enhance interoperability 

• Evaluate the Joint Battlespace InfoSphere (JBI) as a potential solution to interoperability 
problems and the steps required in evolving the current C 4 ISR environment to the JBI 

• Interact extensively with other panels to gather information and to ensure that interoperability 
considerations are captured in the overall study 

The panel conducted an extensive information-gathering campaign. The following is a synopsis 
of the visits, many of which were joint meetings with one or more other panels. 
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Table 3-1. Interoperability Panel Visits 


Dates 

Organization/Location 

Topics 

Other Panels 

Mar 20-21 

Command and Control (C 2 ) 
Training and Innovation Group 
(C 2 TIG), Hurlburt Air Force 

Base (AFB) 

Aerospace Command and Control Intelligence, 
Surveillance, and Reconnaissance Center 
(AC2ISRC) story, Electronic Systems Center 
(ESC) C 2 perspective, Joint Surveillance 

Target Attack Radar System, C 2 ISR 
acquisition, C 2 Battlelab, Joint Expeditionary 
Force Experiment (JEFX) 2000 

All 

April 10-12 

Joint Forces Command, 
AC2ISRC, Joint Warfare 

Center, Joint Battle Center, 
Hampton, VA 

Air Combat Command (ACC) lessons learned, 
time-critical targeting, AOC weapon system, 

C 2 tools, data links, Air Force experimentation 

All 

April 25-27 

Red Flag, Nellis AFB 

Air Warfare Center, Space Warfare Center, 

Red Flag, ESC programs, Boeing independent 
research and development 

All 

May 16-17 

National Reconnaissance Office 
(NRO), Chantilly, VA 

NRO programs 

Technology 

May 18 

Lockheed Martin, Office of the 
Assistant Secretary of Defense: 
Command, Control, 
Communications, and 

Intelligence (OASD/C 3 !), Joint 
Strike Fighter (JSF) Program 
Office, Crystal City, VA 

Project Rainbow, OASD/C 3 ! strategic process 
improvements 

None 

June 12 

Air Force Research 

Laboratory/I nformation 

Directorate (AFRL/IF), Rome, 

NY 

AFRL/IF programs 

Technology 

June 13-14 

ESC; Woburn, MA 

ESC programs 

All 

June 21 

Headquarters U.S. Army/ 

DISC4, Pentagon 

Army enterprise architecture, Army battlefield 
digitization, data models 

Technology, 
People & 
Organization 

June 26-27 

Space and Naval Warfare 

System Command (SPAWAR) 
System Center, SPAWAR 
Acquisition 

Navy C 4 ISR programs, data nodels, facilities, 
architectures 

Technology 

June 30 

Army Program Executive 

Officers (PEO)/C3S, 

Ft. Monmouth, NJ 

4 

Army C ISR programs, architectures, 
battlefield digitization, data models 

None 

July 17 

USS Coronado, San Diego 

Navy command ship and systems 

All 


3.3 Findings and Discussion 

3.3.1 The Meaning and Importance of Interoperability 

In introducing this chapter, we stressed the critical importance of Information Dominance, and 
thus of interoperability, to success in current and future military operations. To amplify and 
substantiate this general assertion, consider the following circumstances on a modem battlefield, 
which may range in scope from a major theater of war down to an apartment building where a 
hostage is imprisoned. 
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• Unprecedented demands for exquisitely precise application of military force are becoming 
routine. These derive from the needs of effects-based operations, from the political 
unacceptability of collateral damage and civilian casualties, from hostile use of deception and 
concealment, and from many other factors. The result is a critical need to collect extensive, 
current, high-quality information on targets and their contexts; to formulate and distribute 
effective mission tasking; to coordinate and control multiple platforms and warfighters in tightly 
timed sequences; and to rapidly assess the status and results of operations. Each step of this chain 
demands seamless interoperability across and within all echelons of the force. 

• Friendly-fire episodes are among the most abhorrent events in war, yet they persist as a 
consequence of breakdowns in critical information processes. The best insurance against these 
tragedies is the ability to maintain a comprehensive situational awareness picture of the 
battlespace and to distribute the appropriate elements of that picture to every participant in real 
time. This, in turn, raises a typical interoperability challenge that today is only partially met. 

• In the post-Cold War era, no aspect of military capability, not even operational effectiveness, is 
more important than affordability. An obvious cost containment strategy is to maximize the use 
of common material solutions across Services and allied nations. Yet differences in policy, 
doctrine, and tactics repeatedly frustrate this approach. Moreover, failure to consider 
interoperability from the earliest stages of defining system requirements and planning and 
executing acquisition programs virtually guarantees later problems, often with expensive fixes. 
These are interoperability problems as surely as any technical incompatibility of equipment, and 
may be harder to solve. 



Figure 3-2. Interoperability Has Many Dimensions 


The diversity of factors that must be harmonized to achieve interoperability is suggested in 
Figure 3-2. In joint or coalition operations, consistent policies and procedures that enable 
sharing and use of information across national and Service boundaries are essential. For each 
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organization and system, interoperability raises a wide range of operational and support 
questions. Finally, in requirements definition and acquisition processes, interoperability 
generates both technical and programmatic concerns. This last aspect is especially troublesome, 
because interoperability is quintessentially a force or system-of-systems proposition, but our 
approach to providing systems focuses on individual programs. Historically program managers 
(PMs) have great difficulty compromising their narrow individual interests for the sake of the 
greater good. Conversely, the individual PM is increasingly seen as being responsible to make 
interoperability happen, yet the largest part of the problem lies in the implementation of other 
systems and is thus beyond the PM’s control. Many of the items listed in Figure 3-2 are further 
explored in this and other chapters of this report. 

These issues are not new. The Department of Defense (DoD) has pursued endless 
standardization initiatives in equipment and procedures. The North Atlantic Treaty Organization 
(NATO) has for decades described rationalization, standardization, and interoperability as a high 
alliance priority. And the impressive record of military successes by the United States and our 
allies since Vietnam attests that these efforts have not been without effect. Today’s joint and 
coalition forces stand without peer in the global security environment and are superbly capable, 
especially in large-scale conflicts. However, two things are different going forward in the 21st 
century. One is the exponential growth in our reliance on information in operations, creating 
both a host of new and more complex interoperability challenges and an ever-greater need to 
deal with them. The other is the reality that missions at the low end of the conflict scale— 
humanitarian relief, evacuations, separation of hostile parties, and the like—will be the most 
frequent taskings of our military forces. The situational ambiguity, lack of clear separation 
among hostiles and neutrals, limits on use of weapons, and other factors in such situations place 
extreme demands on enabling information processes and interoperability. 

As the first step in dealing with the interoperability problem, it is essential that the meaning of 
the term and its many facets and implications be clearly understood. Like many other words 
(architecture comes to mind), interoperability means different things to various individuals and 
organizations 

• To communicators, interoperability usually means the ability to connect nodes and exchange 
messages. The key to this dimension of interoperability is a set of well-defined interfaces across 
which interacting information processes can talk to each other. 

• To information technologists, it usually means the ability to connect equipment via networks and 
to have software applications that cohabitate and (ideally) cooperate when loaded on 
workstations, servers, and nets. The key here is control of the platforms on which applications 
ride, of the shared services they use, and of the networks through which they exchange data. 

• To the warfighter, whose opinion is the one that counts, interoperability means something much 
closer to the definition given earlier: the ability to exchange information in such a fashion that it 
enables cooperative activities to accomplish the mission. This requires that all aspects of 
interoperability be accounted for. 

We have found that the best approach to shed light on this complexity is to construct a hierarchy 
of successively higher levels of interoperability. Figure 3-3 summarizes this construct. 

• At the lowest level, interaction requires that the parties involved share channels for 
communication. These may be landlines, voice radios, data links, satellite communications, or, 
for that matter, couriers on horseback. This layer is labeled “Connectivity” in the figure, and it is 
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characterized by the physical and electronic parameters of a channel; an example would be the 
waveform (frequency, modulation, power level, etc.) of a network radio. Connectivity enables 
the exchange of signals via data links or channels. 

• Next, we require compatibility in the way these channels are used to exchange messages. For a 
voice radio, this can be as simple as a common language and a set of defined terms. In current 
DoD directives, 4 data exchanges are specified by information exchange requirement (IER) 
matrices, which specify transactions among specific platforms and operational facilities in 
response to particular events. For a network or data link, messaging is controlled by a protocol 
that governs such things as the message structure, how data is encoded, how errors are detected 
and corrected, and how networks and channels are managed. A typical example is the network 
protocol and J-series messages defined for Link-16. We call this layer “Communication,” and it 
enables the exchange of messages to achieve shared data. 

• At the next level up, the issue becomes one of compatible information processes that ensure that 
shared data is treated and used consistently. At this point, a common information model, 
discussed in detail later, is absolutely essential. Aspects of this would typically include use of 
appropriate elements of a common operating picture (COP) via shared databases and use of the 
same or equivalent algorithms for data processing. We call this layer “Information Exchange,” 
and it results in shared information among the participating information systems. 
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Figure 3-3. A Hierarchy of Levels of Interoperability Illustrates Its Complexity 


• Yet another set of interoperability factors enters when we address the top layer, involving the 
interaction between information systems and human users. This involves both the human- 
machine interface, especially the need for consistent information presentation, and the underlying 
cognitive processes involved in decision rules, tactics, and training. When this level is fully 


4 Chairman of the Joint Chiefs of Staff Instmction (CJCSI) 6212.0 IB, “Interoperability Supportability of National 
Security Systems, and Information Technology Systems,” May 2000. 
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achieved, the result is what has been called “brain-to-brain” interoperability 5 such that 
commanders and warfighters possess the common understanding that enables cooperative action. 
Accordingly, we call this layer “Cooperation” and characterize it in terms of shared 
understanding. 

• Finally, true joint and coalition interoperability demands a foundation of common policies and 
procedures, drawn in the figure as a background factor spanning the whole interoperability 
hierarchy. This goes beyond considerations of compatible equipment and equivalent tactics and 
training. It involves political issues of information release among nations, unity of command for 
coalition forces, and shared understanding of legal constraints and rules of engagement. With 
this, we have the kind of interoperability that modern warfare requires. 

There may be situations in which levels of interoperability in Figure 3-3 can be achieved despite 
failures or deficiencies in the layers below. In general, however, robust and reliable 
interoperability is best achieved through systematic attention to building each level on a solid 
foundation of the preceding levels, solving problems a layer at a time and ensuring that all 
aspects of the problem are addressed in due sequence. 

3.3.2 Typical Interoperability Problems 

To make the somewhat abstract discussion of the introductory section more concrete, we have 
compiled a few real-world examples. Lessons learned from Operation Allied Force 6 and other 
recent operations, exercises, and experiments illustrate the kinds of non-interoperability with 
which this chapter is concerned. Some problems are susceptible of relatively near-term and 
inexpensive fixes, while others will require anything from system acquisitions and modifications 
to resolution of national information policy issues. A few representative problem areas are listed 
below to give a sense of the situation, along with some candidate near-term actions to address 
them. More pervasive, longer-term approaches are addressed in later sections of this chapter. 

• Inadequate Secure Communications. The coalition force operating in Kosovo found that 
secure communications were sometimes not adequate, in part due to the greater level of technical 
sophistication of U.S. systems. Near-term fix: Work with allies to deploy additional secure radio 
frequency (RF) and landline communications assets, including attention to a coalition encrypted 
Link-16 capability. 

• Separate U.S./Coalition C 2 Networks. Policy issues affecting information sharing with allies 
caused a number of problems. NATO secure networks proved incapable of handling heavy 
traffic such as the air tasking order (ATO) until a work-around involving a scheme to tunnel the 
traffic through other secure channels was devised. Similarly, separate U.S.-only and coalition 
ATOs were required, which created additional work and slowed dissemination of C 2 . Near-term 
fix: Resolve information release policy issues and publish a single ATO, with a U.S.-only annex 
if required for specific content. Work with allies to deploy higher capacity secure networks and 
to implement guards and other measures as required to allow connectivity. 

• Inadequate Management of Network Bandwidth and Spectrum. Central coalition 
management of limited network capacity and spectmm allocations continued to be a problem, as 
in earlier operations. Multiple approvals, each taking time, were required to use needed 
frequencies. Near-term fix: Develop and implement improved tools and procedures, including 


5 Julian Ranger, Through Life Interoperability Program (TULIP) Handbook , STASYS, Ltd., 1999. 

6 Initial Report: the Air War over Serbia, Aerospace Power in Operation Allied Force , United States Air Forces in 

Europe, Studies and Analysis Directorate, April 2000. 

3-8 



use of available systems for monitoring and managing Link-16 and other key data links, and pre¬ 
coordination of spectrum allocation with host nations. 

• Incompatible U.S./Coalition Systems in the Coalition Air Operations Center (CAOC). The 

U.S. employs the Contingency Theater Air Planning System, and is moving toward the even more 
sophisticated Theater Battle Management Core System (TBMCS), while NATO uses different 
systems with a number of incompatibilities. This hindered coordination among coalition forces. 
Near-term fix: Work with allies to establish better collaboration tools and procedures, including 
automated translation of files and messages to bridge system incompatibilities, and use exercises 
to better define problems and identify solutions. 

• Incompatible Procedures for the Same Aircraft or Weapons. In some cases, air forces 
employing the same systems had evolved different tactics and procedures, complicating 
cooperative operations. Near-term fix: Use joint and coalition exercises, training and operations 
to develop common tactics, techniques, and procedures (TTPs). 

• Multiple Specific Disconnects. A number of specific problems have been identified, including 
inconsistent time references for Link-16 messages, inconsistent callouts from identification 
systems, limited interoperability of ground force and aircraft radios, and many others. Near-term 
fix: Case by case basis, clearly define the problem and seek affordable (especially through 
procedure changes) corrective actions. 

3.3.3 Interoperability and the Expeditionary Aerospace Force (EAF) 

The Air Force is well along in transitioning to the EAF and now plans to go to war using 
Aerospace Expeditionary Forces (AEF). This concept of operations (CONOPS), when fully 
developed, calls for the Air Force to deploy a precisely tailored force, including the required 
communications, in as little as 24 to 48 hours to meet national requirements. This poses 
enormous interoperability challenges. Training and maintenance are still done by Numbered Air 
Forces (NAFs) using procedures that are often peculiar to a particular theater, while the AEF that 
goes to war is likely to consist of units chosen from various NAFs. It is vital that the various 
units of an AEF be interoperable, including all aspects addressed in Section 8.1, in order to be 
ready to generate sorties and operate as a cohesive force immediately upon arrival in theater. It 
would be highly desirable as part of the work-up to an AEF’s window of vulnerability for 
deployment to ensure that the information systems, TTPs, support systems, and other essential 
assets are fully compatible. In the long term, the JBI construct greatly simplifies this problem, 
but the Air Force requires a near-term solution as well. 

The Navy faced a similar problem in dealing with the ships that form a battle group and found 
that they sometimes went to sea with incompatible systems. To solve this problem, the Navy 
developed the Distributed Engineering Plant (DEP), a network of simulation facilities to test the 
interoperability of the systems installed on the ships, with the software load that is heading for 
sea, before the battle group sails. We recognize that the AEF problem differs, primarily because 
the AEF has a more flexible schedule. The Navy battle group’s composition and departure date 
are known well in advance. The AEF may be dynamically configured on 24 hours’ notice. 
However, there is a rough equivalent in the 3-month deployment vulnerability window through 
which the AEFs rotate. Interoperability of like wings within the AEF is tested during the 
6-month Normal Operations Phase II. The AOC, lead wings, assigned wings and squadrons, and 
the associated lead mobility wings should be tested in a DEP-like facility before beginning the 
6-week schedule of exercises in the work-up phase. This facility should also simulate standing 
AOCs, with which the AEF will most likely operate. This will enable the exercises to be used to 
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train the people and check out the procedures, rather than to verify the interoperability of the 
equipment. A DEP-like facility should also simulate low-density, high-demand assets for 
interoperability tests. Ideally, such a facility would also simulate the elements of other services 
with which the AEF will most likely interact. In our recommendations, we offer a specific 
approach to achieve this through a “Distributed C 4 ISR Simulation Network.” 

AEF interoperability extends to more than Air Force airplanes and command centers. Long-haul 
communication for reachback to home theaters is likely to require that communications assets 
deploy even before combat forces. Depending on the level of development of the countries and 
bases hosting the AEF, this may entail considerable equipment and require interoperability with 
a wide variety of space and terrestrial communications infrastructure. Ideally, both routine 
training and preparation for an actual deployment should include work with joint and coalition 
forces likely to be involved. 

The Office of the Secretary of Defense, Under Secretary for Acquisition and Technology and the 
Joint Staff J-8 have established a program to develop a Joint Distributed Engineering Plant 
(JDEP), but that program has been underfunded. The joint group has also begun to explore the 
Joint Theater Air and Missile Defense mission. The Air Force should either create a Program 
Objective Memorandum (POM) for the JDEP and ensure that it meets the needs of the EAF, or 
develop an Air Force facility like the Distributed C 4 ISR Simulation Network to meet the needs 
of the AEFs and plan to eventually tie it to the JDEP. Facilities that would be candidates for 
integration into a JDEP network include those of the C 2 TIG, the ESC C 2 Unified Battlespace 
Environment (CUBE) and the Theater Air C 2 Support Facility (TACCSF), as well as new 
facilities like the proposed experimental C 2 centers at Langley and Nellis AFBs. 

3.3.4 Joint and Coalition Interoperability 

Following the Panel Charter, we have devoted considerable attention to the subject of joint and 
coalition interoperability. In addition to the discussion below, Section 2.6.9 of the Concept and 
System Definition Panel Report in the previous chapter highlights some of today’s most critical 
operational interoperability problems. The primary focus of this study is on Air Force problems, 
processes and systems, with a goal of having the Air Force “linked by 2005.” However, almost 
any foreseeable combat operation, and many humanitarian and peacekeeping missions, will 
involve joint or coalition forces. Thus, while the C 2 interoperability challenge within the Air 
Force alone is significant, the effort must clearly be extended to the total ensemble of forces 
involved in an operation. It’s difficult to imagine a scenario where the operational limitations 
created by a lack of interoperability, as we know them today, can be solved by even perfect Air 
Force interoperability. The task of achieving an interoperable joint or coalition force is daunting 
and has proved intractable; it impacts everything from doctrine and national policy to systems, 
processes, procedures, and missions. Success in coalition operations will often yield important 
political and diplomatic benefits and may be essential due to the need for an international 
mandate and for geographic access. 
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3.3.4.1 A Problem with Many Dimensions 

Interoperability in general, but especially in the context of joint and coalition operations, is 
impacted by virtually every aspect of the forces involved, including 

• The Operational Dimension: policy and doctrine, training, the requirements process, and rules 
for the conduct of joint and coalition operations 

• The Technical Dimension: performance capabilities of various systems, conformity to interface 
standards and common procedures, information assurance, and overall levels of technical 
sophistication of participating forces 

• The Programmatic Dimension: specification and fielding of interoperable systems, 
interoperability testing and certification, and resolution of interoperability issues involving 
multiple systems and agencies 

• The Support Dimension: compatibility of weapon systems and multiple support environments, 
especially under deployed and austere conditions 

As summarized in Section 3.3.2, recent contingencies, as well as tests, exercises, and 
experiments, have uncovered deficiencies and illustrated the consequences of joint or coalition 
interoperability shortfalls. To choose one example among many, ambiguous “identification, 
friend, foe, or neutral” declarations, as were identified in a 1994 Link-16 test at Mountain Home 
AFB, can have a debilitating impact on rules of engagement (ROE) and the success of the air 
war. When System “A” can flag targets as “friendly,” “presumed friendly,” “unknown,” 
“presumed hostile,” and “hostile,” and System “B” has only “friendly,” “unknown,” and 
“hostile,” then system “A” displays “presumed friendly” as “unknown.” At a minimum, the 
result is confusion in what should be a simple task of handling a common track. More seriously, 
it’s easy to envision this situation leading to fratricide or to a friendly aircraft’s being surprised 
by a hostile. In another case, lessons learned from the Kosovo operation show that various 
Link-16 terminals that comply with the applicable Standardization Agreement nevertheless had 
incompatibilities that prevented correct information exchange due to such problems as 
inconsistent definitions of the time stamp incorporated in a report. The overall message is that 
interoperability problems are numerous, often subtle, and frequently difficult to diagnose and 
correct. 

It’s difficult to set the right boundaries on interoperability requirements, largely because it’s 
impossible to predict the next fight. Which forces from which Services and nations will 
participate in which roles are matters unlikely to be settled until after a crisis erupts. Moreover, 
the need for interoperability increasingly extends to non-Defense government entities (such as 
the Department of State, Coast Guard, and Department of Transportation) and even to non¬ 
government organizations (NGOs), especially in humanitarian missions. A prime requirement is 
thus that joint and coalition interoperability be general and robust, not requiring the kind of ad 
hoc work-arounds that have been used to patch disconnects in recent engagements and not 
assuming that any single country or Service has sole responsibility to correct interoperability 
problems. Platforms should be able to communicate, command centers should be able to 
exchange classified information, and commanders should have a shared and consistent view of 
the situation, regardless of which systems are in use or who provides them. Today, the U.S. 
armed forces and their allies are far from that ideal. 

Difficulties in interoperability with coalition partners become evident every time we operate 
together or conduct a joint or combined exercise. We learn the lessons over and over, yet too 
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often seem unable to acquire systems, develop TTPs, establish compatible support environments, 
and conduct training so as to achieve the required level of interoperability. To take a simple but 
suggestive example, when something as basic as a secure telephone is procured as a NOFORN 
(U.S.-only) system, an obvious and powerful instrument of interoperability is frustrated. 

This is not to ignore the reality that some information, and even some technology and systems, 
will not be shareable with our allies. But such decisions must be balanced against the 
overarching need for interoperability, and effective means to command, control and support a 
joint or coalition force must be assured. To return to the CAOC example cited earlier from 
Operation Allied Force, where we were operating with primarily NATO allies (when the United 
States decides to release sensitive information, it’s safe to say that NATO countries get it first), 
we found the need to restrict ATO information on selected systems. The Joint Force Air 
Component Commander (JFACC), Lt Gen Michael Short, needed as always, to get the tasking, 
Airspace Control Order (ACO), Special Instructions, and other C 2 information to all the forces in 
the coalition. He later said that there was nothing that could not have been handled by a U.S.- 
only cell within the CAOC, and that we should never again publish separate ATOs. Information 
exchanges that cross boundaries between differing levels of classification will be a continuing 
challenge, but a combination of technical, procedural, and policy measures must be employed to 
simultaneously ensure information security and provide timely and robust interaction within the 
elements of the force. 

Information release is essentially a policy issue, but its resolution needs to be complemented by 
technical solutions that ensure that coalition secure systems have adequate capacity and that 
measures such as software guards to isolate computing environments at different levels of 
classification are used when appropriate. The key to success is to develop C 2 systems that are 
flexible enough to interface with other agencies and able to protect classified information in such 
interactions, together with information release rules and procedures that account for the 
operational realities of employing joint and coalition forces. Such a strategy can only succeed if 
it is rooted in an architecture that establishes the information structure to which the elements of a 
joint/coalition force must conform and the interfaces across which information is exchanged. 
Much of the remainder of this chapter is devoted to various facets of C 2 architecture and its 
implementation. 

There are additional constraints on achieving joint or coalition interoperability that are inherent 
in the way the United States and its allies acquire systems. Some can be overcome, and some 
probably cannot. First, and perhaps foremost, is the system-centric approach to acquisition. 
Historically, the focus in all Services has been to get the operational capability of a system 
fielded with little or no regard for interoperability with the rest of the force. Interoperability has 
not, until quite recently, been a key performance parameter (KPP). Legacy systems present a 
bewildering array of interfaces, and often require gateways to allow information exchange. 
Force-level architecture has consisted of little more than a catalog of standards, and competitive 
pressures have given industry an incentive to deliver closed, proprietary systems. Technology 
transfer issues and additional proprietary issues relating to foreign industry hinder coalition 
interoperability solutions. Compliance mechanisms for interoperability with enforcement power 
from the requirements definition stage through production and delivery of systems have been 
lacking. Cost is often cited as a rationale to compromise interoperability because there is no way 
to account for economic impacts at any level other than an individual system or program. In 
short, the entire system development process conspires against interoperability. 
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3.3.4.2 Interoperability Initiatives 

Even so, some recent initiatives offer hope. DoD has developed a C 4 ISR Architecture 
Framework 7 that establishes the construct of operational, technical, and system views of an 
architecture, which may apply to a system, a family of systems or a system of systems 
(Figure 3-4). Each view is defined by a set of mandatory and optional products. The framework 
also provides common definitions, and common references (building blocks), for example, the 
Uniform Joint Task List, Shared Data Environment, Technical Reference Model, Joint Tec hn ical 
Architecture, and the Defense Data Dictionary System. The framework provides a basis for 
attacking the architecture problems described above. The Joint Staff is drafting a Joint 
Operational Architecture (JOA), supported by a set of Joint Mission Architectures (JMAs). If 
carefully developed and rigorously applied, these may be important elements in a broad 
interoperability strategy, initially for U.S. forces and potentially with allies. 

DoD policy has established interoperability as a KPP, and CJCSI 6212.0IB spells out the 
process, roles and responsibilities of the Defense Information Systems Agency (DISA), 
especially the Joint Interoperability Test Center (JITC), the Joint Staff, and the Services in 
achieving interoperability certification for new systems. The instruction places heavy emphasis 
on proper treatment of interoperability in requirements definition and on the application of the 
C 4 ISR Architecture Framework. The approach is centered on the definition of a set of critical, 
top-level IERs, and the limitations of this view of interoperability are discussed in a later section 
of this chapter. 

DoD’s grand strategy for achieving Information Dominance is the Global Information Grid 
(GIG)—the overall Defense Transformation Initiative aimed at providing the information 
infrastructure required by U.S. forces in the 21 st century. It responds to the Clinger- Cohen Act 
of 1996, to various mandates for Defense reform, and to the concept of Information Dominance 
in Joint Vision 2010 and Joint Vision 2020 (JV2010 and JV2020). The JOA is being defined as 
the Operational Architecture View of the GIG. The Deputy Secretary of Defense recently issued 
a GIG Guidance and Policy Memorandum. 8 This directive provides for the GIG “as a 
cornerstone in” DoD’s “Revolution in Military Affairs, the Revolution in Business Affairs, and 
in enabling the achievement of Information Superiority.” A GIG Capstone Requirements 
Document (CRD) has been drafted by U.S. Joint Forces Command. The GIG is defined as “the 
globally interconnected, end-to-end set of information capabilities, associated processes, and 
personnel for collecting, processing, storing, disseminating and managing information on 
demand to warfighters policy makers and support personnel.” Both an overall vision and a GIG 
Systems Reference Model have been developed. 


1 DoD CJlSR Architecture Framework, Version 2, 18 Dec 1997. 

8 DoD CIO Guidance and Policy Memorandum 8-8001, March 31, 2000—Global Information Grid. 
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System Capabilities 


Source: “ C 4 ISR Architectural Framework,” Version 2.0, 18 Dec 1997 


Figure 3-4. Three Views That Define an Architecture 


OASD/C 3 I has been designated DoD’s Chief Information Officer (CIO), and CIOs have also 
been designated for the Services, Unified Commands, and major Defense Agencies. A CIO 
Executive Board was also mandated by the Act. Under Title 10 U.S. Code, Section 2223, as 
amended by Clinger-Cohen, the DoD CIO has statutory authority to make and approve IT budget 
requests, ensure IT interoperability, ensure application of standards, and eliminate duplication. 
Overall, the DoD CIO community may provide an important forum and mechanism for attacking 
the problems that have bedeviled joint interoperability. OASD/C 3 I is revising the applicable 
policy documents and has under way a wide variety of activities aimed at various aspects of 
interoperability. JITC has extensive experience in working interoperability problems, possesses 
valuable facilities for testing, and has taken a proactive stance in working with programs to 
address interoperability requirements. A less formal but nonetheless effective forum for working 
interoperability issues has been formed by the concerned PEOs of the three Services. 

Today, the GIG is conceptual, but as it is implemented in operational architectures, acquisition 
programs, and other concrete measures affecting DoD information systems, it may help to 
provide the “big picture” within which legacy stovepiped systems can move toward the required 
levels of integration and interoperability. The scope and purpose of the GIG substantially 
overlap those of the JBI (Chapter 8), and it seems likely that the JBI, which is better defined and 
more in tune with modem technology than the GIG, will supplant it over time. 

Finding affordable ways to improve the interoperability of legacy systems, as well as 
overcoming inertia and parochialism within Services and their programs, remain as challenges. 
However, interoperability is receiving unprecedented attention, and the creation of the KPP 
provides a badly needed incentive for individual PMs to treat interoperability with the priority it 
deserves. 
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33.4.3 Air Force-Army Interoperability Issues 

Close linkage between air and ground forces is obviously essential to mission success and 
fratricide prevention. Both C 2 centers and individual units and platforms are involved. The 
Army Battle Command System (ABCS) in a Tactical Operations Center must interact closely 
with the TBMCS in an AOC. Currently, coordination is accomplished through a collocated 
Battlefield Coordination Detachment (BCD) in the AOC, and Army deep operations planning 
and execution require timely information exchanges among the Deep Operations Coordination 
Center (DOCC), the AOC (through the BCD) and the Air Support Operations Center (ASOC). 
Progress has been made, but a number of interoperability issues remain. 

ABCS components that require interoperability in various forms with the Air Force C 2 
environment include 

• Global C 2 System-Army (GCCS-A): GCCS-A is the Army component of the GCCS initiative. 
It provides automated C 2 tools to enhance warfighter capabilities during joint and combined 
operations. 

• Maneuver Control System (MCS): MCS is the battle command system for the maneuver 
commander and operational staffs. It provides the common tactical picture, planning aids and 
battle tracking and execution capabilities. Its products include friendly unit locations, operational 
plans, and other operational data essential for battlespace awareness. 

• Advanced Field Artillery Tactical Data System (AFATDS): AFATDS is the fire support 
component of the ABCS. It provides tools for planning, coordination and control of fire support 
assets. 

• All Source Analysis System (AS AS): AS AS is the intelligence electronic warfare element of 
ABCS. It is the primary intelligence tool at battalion through corps levels to fuse multi-source 
information into a single threat picture. It compiles intelligence information into databases that 
support intelligence preparation of the battlefield (IPB), situational awareness, and target 
nomination. 

• Tactical Airspace Integration System (TAIS): TAIS is an information management system 
that supports Army Airspace C 2 at corps, divisions, and BCD. 

• Automated Deep Operations Coordination System (ADOCS): The Army has developed 
ADOCS as a management tool to coordinate deep operations. ADOCS enables accelerated 
mission planning and airspace coordination. It could be integrated with the ATO databases. 
ADOCS is interoperable with GCCS, GCCS-A, AFATDS, ASAS, and ADA. Third Army (Army 
Forces Central Command) is evaluating its potential to support joint warfighting. 

• Air Mission Planning System (AMPS): AMPS provides a capability to rapidly transmit Army 
aviation air routes and other functions to TAIS. The ground liaison officer and the suppression of 
enemy air defenses (SEAD) squadron can use it to see the Army aviation air routes and changes 
that may be made to them while helicopters are en route. 

The Air Force TBMCS and Army Project Managers for GCCS-A, ASAS, AFATDS, and the Air 
Missile Defense Work Station (AMDWS) signed an Interface Control Document (ICD) in 1998. 
Below is a summary of the situation: 

• TBMCS—GCCS-A: The ICD calls for interfacing via exchange of U.S. Message Transmission 
Format (USMTF) messages. The current plan is to use the 2000 version of USMTF. GCCS-A 
interfaces with TBMCS to provide target nomination. The ATO and ACO are provided from 
TBMCS to GCCS-A. 
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• TBMCS—MCS: The MCS contract specifications include a requirement for MCS interface 
with TBMCS. Specifics of how this interface will occur need resolution. 

• TBMCS—AFATDS: AFATDS interfaces with TBMCS at the AOC and the ASOC. The 
interchange will be via USMTF or USMTF-like messages. This issue is assessed as yellow, 
turning green when TBMCS is fully developed and fielded. 

• TBMCS—ASAS: ASAS interfaces with TBMCS at the AOC. ASAS will exchange intelligence 
information through the Modernized Integrated Database (MIDB) upon completion of ASAS 6.2 
in September 2000. Should this approach not work, there needs to be a direct interface to support 
en route aircraft retasking. 

• TBMCS—AMDWS: TBMCS will exchange data with a single designated AMDWS. The 
designated AMDWS will further distribute the ATO and ACO. 

• TBMCS—TAIS: These systems are not interoperable. TAIS has demonstrated that it can 
exchange USMTF ATO and ACO messages with TBMCS. The PM for Air Traffic Control 
acknowledges the requirement for TAIS to be interoperable with TBMCS. TAIS is implementing 
the Joint Common Data Base and should then be interoperable. 

Specific issues that need attention include 

• Disconnects between TBMCS and ABCS that inhibit dynamic targeting and real-time force 
coordination must be resolved. If the GCCS vision of a real-time COP, or Family of Integrated 
Operational Pictures (FIOP), is realized, it will support database-to-database interactions and help 
ensure consistent, timely views of the battlespace by both air and land commanders. An 
important aspect of this is timely exchange of intelligence information; an example would be use 
of ASAS feeds in the AOC process for IPB. Another is the need for current, accurate friendly 
force locations in the situational awareness picture in the AOC and in Air Force cockpits. 

• Better means are needed for dynamic tasking and cross-cueing of Air Force and Army 
intelligence, surveillance and reconnaissance (ISR) assets to locate and identify targets. For 
example, the AOC collection manager should have a data link to the DOCC to nominate targets 
and allow cross-cueing of Army ISR assets (for example, GUARDRAIL Common Sensors and 
Fire Finder radars). Likewise, the DOCC should have a data link to the AOC for tasking Air 
Force assets. Procedures should support dynamic retasking of collection assets to support real¬ 
time targeting. 

• The ATO process and timeline need to better support Army flight operations. The Air Force, 
Navy, and Marine Corps control aircraft operations by tail number. In contrast, Army aviation 
assets are controlled by unit assignments. The current 72-hour ATO cycle is too long and 
inflexible to accommodate Army flight operations. In addition preplanned, deliberate Army 
flying missions that cross the forward line of troops (FLOT), including deep attack and air assault 
missions should be in the ATO to ensure search and rescue and SEAD support. Better 
deconfliction of airspace and missions is another important consideration. 

• The AOC needs better means to initiate and control attack of mobile targets. Currently, Desired 
Mean Points of Impact (DMPIs) are required to put a target on the draft Joint Integrated 
Prioritized Target List and Target Nomination List. Mobile targets do not have DMPIs in a 
prepared database like fixed targets do in the MIDB. Currently, in exercises, the BCD must 
create DMPIs for mobile nominations, which is a time-consuming process. It will be impossible 
to add DMPIs in a real-world situation where the ground forces may nominate dozens of targets. 

• AFATDS interoperability with TBMCS at both the AOC and the ASOC is essential for 
integrating battle plans and coordinating situational awareness. Air Force and Army plans call 
for TBMCS—AFATDS interoperability via eight different USMTFs that focus on targeting and 
friendly unit information. AFATDS should be able to dynamically retask assets to facilitate the 
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attack of time-critical targets. By implication, close coordination between ABCS systems and the 
Battle Command Center of the next-generation Air Force C 2 structure will be essential. 

• Close air support (CAS) forces must have improved situational awareness to understand the 
dynamics of mobile ground operations. A key deficiency in air-to-ground operations is that 
ground forces are not visible in the Joint Data Network (JDN)—the joint tactical data link that 
enables all participants in a theater air defense organization to create the single integrated air 
picture, manage air and maritime battlespace, and conduct identification—friend or foe. One 
approach might be a gateway between the Army Enhanced Position Location Reporting 
System/Variable Message Format (VMF) ground network and the JDN so that CAS aircraft can 
have a more accurate location of friendly ground forces to reduce fratricide and allow more 
accurate air strikes in proximity to the FLOT. 

3.3.4.4 Air Force-Navy Interoperability Issues 

The Navy and Air Force have fewer issues with fratricide and coordination of flying and surface 
forces, but important interoperability matters nevertheless require attention. In some scenarios, a 
“JFACC Afloat” will run the air war, at least in its early stages, from a Fleet Command Ship 
such as the USS Coronado, and assigned Air Force units must be prepared to operate with such 
an AOC. Naval aviation must be able to receive the ATO and smoothly feed tasking into its 
mission planning systems. Dynamic control of operations, retasking of aircraft in flight, 
coordination of strikes on time-critical targets, and combat search and rescue are just a few of the 
areas where high levels of interoperability are critical. 

In future coalition operations, the Air Force is likely to operate with allied navies. Examples of 
potential allied contributions, the first three of which could entail interoperability with Air Force 
aircraft, include 

• Development of new guided missile anti-air warfare frigates with state-of-the-art 3D radars and 
longer-range surface-to-air missiles (France, Germany, Italy, Spain, and UK) 

• Development of new amphibious warfare ships (Italy, Spain, and UK) 

• Ships for surface surveillance (multiple nations) 

• Continued proficiency in the key niche area of mine countermeasures (France, Germany, 
Netherlands, and Spain) 

The following Navy systems must interoperate with Air Force C 4 ISR systems, tallied in rough 
order of importance: 

• Joint Tactical Information Distribution System (JTIDS)-VMF. Air Force and Naval Air 
cannot work together without Link-16. The greatest challenge is to get the message formats into 
each airplane as needed to accomplish the mission. The Navy and the Air Force use different 
message formats to pass data and information, often resulting in incompatibility. Other data links 
(Situation Awareness Data Link [SADL], Information Dissemination Management [IDM], etc.) 
may also present issues. 

• GCCS-Maritime (GCCS-M). This will be an essential provider of data to the COP/FIOP for all 
users, including the Air Force. 

• Global Combat Support System-M (sometimes known as the Navy Tactical Command 
Support System). Compatibility is essential to joint logistics planning and execution. 

• AEGIS. This is an essential participant in mutual support among all services in the littoral 
battlespace for both air-air and theater ballistic missile defense operations. 
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• Joint Mission Planning System (JMPS). This is intended to be a joint system that ensures 
compatible mission planning; there could be issues if Service-specific solutions are employed. 

• JSIPS-N, including the Tactical Input Segment. Compatibility is essential for joint support 
with tactical imagery. 

• Cooperative Engagement Capability (CEC). This could become the basis for the Joint 
Composite Tracking Network (JCTN), and will be a major element in joint air defense operations 
in the littoral. 

• Advanced Combat Direction System. This is being implemented on attack carriers, but is 
currently not even interoperable with AEGIS, let alone Air Force systems. 

• Joint Tactical Radio System (JTRS). This and other common tactical radios will be critical in 
joint operations. 

• TALON Gateway. This Air Force Tactical Exploitation of National Capabilities Program 
(TENCAP) initiative is to put a “translator” onto a widebody aircraft to send and receive 
ultrahigh frequency over-the-horizon information, translate it into the proper format (Link-16, 
SADL, and IDM), then retransmit the data or imagery to the appropriate fighter aircraft. This 
system could be the model for future efforts to “unstovepipe” systems. 

• Airborne Broadcast Information. This effort, sponsored by Air Mobility Command (AMC), is 
a direct descendant of the Multi-Source Tactical System developed by Air Force TENCAP. 

AMC is purchasing many of these systems for its aircraft to give them enhanced situational 
awareness; interoperability with supported Navy units would be valuable. 

• Radiant Topaz. This is a Surveillance, Reconnaissance, Management Tool for collection 
management. 

• Multilevel Security (MLS). In general, a robust joint solution to the MLS challenge is a major 
issue. 

• Meteorology and Oceanography (METOC). The Navy has a very robust system here that 
could help meet the needs of the other Services. 

3.3.4.5 Air Force-Coalition Interoperability Issues 

Economic, doctrinal, and regional concerns intervene to inhibit interoperability between the 
United States and its allies. Many of our partners in NATO and elsewhere understand that they 
cannot reach parity with the United States in levels of C 4 ISR investment. Especially when the 
United States does not have a robust and proven CONOPS for information-enabled operations in 
place, allies facing resource constraints and competing priorities can conclude that 
interoperability is not achievable. In addition, allies face difficult decisions between buying U.S. 
systems as a route to interoperability and supporting their own or their neighbors’ industries; 
issues of workshare and releasability of information and technology are crucial in this context. 
The United States has not always been sufficiently proactive in bringing allies into system 
requirements definition and program planning to allow time for mutually acceptable acquisition 
decisions to be worked out. 

We can illustrate trends in C 4 ISR that may contribute to interoperability problems in terms of the 
conventional three-level hierarchy of theater tactical networks as shown in Table 3-2. 
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Table 3-2. Network Tiers in the U.S. C 4 ISR Structure 


Network Tier 

Existing/Planned Systems 

Joint Planning Network (JPN) 

• Defense wide-area networks (Non-Secure Internet Protocol 
Router Network/Secret Internet Protocol Router Network 
(SIPRNET), Joint Worldwide Intelligence Communications 
System, etc.) supporting GCCS, Joint Deployable Intelligence 
Support System, Defense Message System (DMS) 

• Secure voice and data, Global Broadcast System, video 
teleconferencing (VTC), etc. 

• Planning networks (for example, TBMCS) 

JDN 

• Tactical Data Links (Link-11, Link-16, etc.) 

• Theater and national data broadcasts (Tactical Data 

Distribution System, Tactical Information Broadcast Service, 
etc.) 

• Common high-band data link 

JCTN 

• Sensor and weapons networks 

• CEC, sensor-to-shooter subnets 


The lowest tier of the table has the most timeliness and the most direct link between information 
and weapon employment. These networks connect information sources to the combat direction 
system of a ship, a tactical operations center, an aircraft mission computer, or a weapon guidance 
system. The middle tier provides cueing, situational awareness, and force coordination. The 
highest tier accommodates information exchange, coordination, planning, and contextual 
information. In general, the scope of network operations decreases and responsiveness increases 
in moving down the tiers. Using this construct, Table 3-3 highlights the present and near-term 
prospects for coalition interoperability. 


Table 3-3. Assessment of Coalition Network Interoperability 0 


Network Tier 

System 

interoperability Assessment 

JPN 

DMS, TCI/IP-based messaging 

• No blanket access to SIPRNET 

• Information exchange between networks 
depends on coalition MLS solution 


GCCS 

• Allies buying subsets; releasability of some 
segments is uncertain 


TBMCS 

• Allies buying subsets; releasability of some 
segments is uncertain 


Secure Voice and VTC 

• Issues with secure terminal equipment, 

Fortezza encryption cards, bandwidth 
limitations, etc. 


Intelligence systems 

• Allies divided by access to secure networks 

JDN 

Data Links 

Interoperability and data sharing likely to be 
extensive 

JCTN 

Sensor/weapons networks 

Allied forces are likely to be excluded by U.S. policy 
and limited common system inventories 


9 R.R. Odell, P. Morley, K. Gause, and F. Ruiz-Ramon, Toward a US Navy Strategy for C 4 1 Interoperability with 
Allies, CAN Research Memorandum, 1999. 
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Overall, there are three reasons why problems with C 4 ISR interoperability should be expected. 
First, the U.S. JPN will make the most intensive use of broadband satellite communications, 
creating an investment issue with our allies. Second, the proliferation of U.S. and other nations’ 
networks will compound the interoperability challenge, especially in terms of achieving MLS 
solutions. Finally, U.S. advances in IT are likely to reinforce a U.S. preference for employing 
U.S.-only networks; access and information releasability will continue to be vexing problems. 

The limited ability of allies to procure U.S. systems, for both resource constraint and industrial 
policy reasons, will be serious limiting factors. Interactions among the three tiers of Tables 3-2 
and 3-3 are important. The increasing importance of information processes at the JPN level, the 
proliferation of networks, the limited releasability of certain key technologies, the wide spread in 
access to satellite communications bandwidth, and the limited availability of U.S. sensor-to- 
shooter chains to allies will limit the role their forces can play in major operations. U.S. forces 
will be in a superior position with respect to access to information and often will not know what 
access their allies have; allied access to U.S. networks is likely to continue to be unsatisfactory. 
Specifically: 

• In coalition operations, U.S. armed forces are unlikely to change their C 4 ISR suites for the sake of 
coalition interoperability, increasing the importance of linkages to allied networks such as the 
NATO CRONOS wide-area network. 

• Allied access to U.S. networks will be restricted and variable. Some nations will have highly 
sensitive access, while others will not. Guards that allow connectivity between U.S. and allied 
networks in an MLS environment will be critical. 

• Restrictions of the U.S. National Disclosure Policy are likely to be most restrictive at the level of 
the JPN. 

As a result: 

• Future coalitions will be stratified into groups of nations with various degrees of C 4 ISR capability 
and interoperability with U.S. systems. 

• C 4 ISR interoperability is likely to be poor for the JPN and sensor-to-shooter chains. 

• The task of diagnosing C 4 ISR interoperability problems with allies and setting requirements will 
be scenario-dependent. 

• U.S. responsibilities in coalition operations for information operations and protection could 
increase. 

3.3.5 Critical Processes for Interoperability 

Joint and coalition operations, especially in the emerging expeditionary force model, demand a 
level of interoperability that our existing methods of acquiring and employing systems are 
unlikely to satisfy. If interoperability is to be achieved, technical and operational solutions must 
be underpinned by a set of processes that can actually deliver the desired result. Among the 
most important of these are the processes governing 

• Requirements analysis and definition for systems, systems of systems, and families of systems 

• The definition, evolution, and application of architectures at these same three levels, including the 
choice and enforcement of standards 

• The acquisition, testing, and long-term modification and upgrading of systems 
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• The development and implementation of joint and coalition doctrine, tactics, procedures, training, 
and exercises that make interoperability a routine and accepted fundamental of military 
operations 

Unfortunately, the processes that prevail in these areas today are generally much more of a 
hindrance than a help. Process reform will be one of the most important, but also most difficult 
and time consuming, aspects of migrating our legacy forces and systems toward the vision of 
JV2020. Once again, the Internet and commercial practices have much to teach DoD. We seek 
an approach that can drive critical processes toward the broad goal of interoperability while 
balancing fiscal and operational priorities, minimizing the disruption of ongoing programs, and 
involving all interested parties, from policy setters to system developers to warfighters. Other 
panel reports concentrate on operational, acquisition, human factors, and technology processes 
for C 2 . Here, we consider some aspects that are especially relevant to our area. 

3.3.5.1 The Problem Today 

In working on this study, we have repeatedly come up against the problems that result from a 
platform-centric view of military systems. Requirements definition, which is the bedrock to 
which the whole acquisition process is anchored, remains fixated on individual systems to meet 
specific operational needs, identified by narrow groups of users. There is little or no 
consideration of how synergy among the diverse elements of an integrated force might deliver 
more capability at less cost. Compounding the problem, DoD and the Services are only 
beginning to think about operational architectures and system-of-systems frameworks that might 
provide the kind of context requirements developers need in order to break out of this mindset. 

In short, what we have today is mostly a recipe for non-interoperable stovepipes. We pay a 
heavy price both in the kind of operational problems described earlier and in individual system 
costs driven up by the inability to use common solutions to common needs and the desire to 
optimize each system instead of the capabilities of the force to which the system contributes. 

More recently, a great deal of emphasis has been placed on the infrastructure dimension; 
examples include the Defense Information Infrastructure Common Operating Environment 
(DII COE) as a way of standardizing information system platforms and Link-16 as the universal 
tactical data link. In the process, there has been a tendency in DoD to apply standardization 
mandates, sometimes before the thing being mandated was mature enough for real-world use. 
Our examination of the history of TBMCS suggests that a large part of its history of problems is 
due to the fact that it was committed to an early version of DII COE that lacked both the 
functionality and the stability to support it. In every case, the focus of interoperability initiatives 
has been on the lower levels of the hierarchy in Figure 3-3, especially on communications 
interoperability, when, in fact, many of the most difficult challenges lie at the higher levels. 

3.3.5.2 Commercial Practice 

The practice in the co mm ercial world has rapidly evolved from one based on closed proprietary 
architectures with few broadly accepted standards to one of open, agreed-upon standards for 
most layers of the architecture. In addition to the technical lessons the private sector has to 
teach, we are interested in the processes used to achieve these results. Some of them are 

• Individual companies see their financial interest in value-adding products that exploit a common 
infrastmcture rather than in control of that infrastructure. This actually creates powerful 
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incentives to share information and agree to compromise on definition of standards so that the 
foundation on which competitive advantage is then erected can be put in place quickly. 

• Standards activities are community based, and arise from communities of interest in specific 
domains such as banking, product engineering, and music. While standards committees are 
notoriously messy, time consuming, and contentious, they have an excellent track record in 
hammering out workable compromises in time to meet the needs of the participants. 

• Standards are primarily oriented to interfaces and shared processes, rather than products, although 
the dynamics of the marketplace may create de facto standards around products like Microsoft 
Windows. The minimum set of standards that can ensure interoperability, both generally and 
within a specific domain, is all that will be developed. The outstanding example is the Internet 
protocol stack, especially Transmission Control Protocol/Intemet Protocol (TCP/IP), and other 
effective standards have been widely used file formats (GIF, JPG, etc.) and popular application 
programming interfaces (APIs). 

The evolution of the commercial marketplace from competing proprietary architectures (IBM, 
Burroughs, and others) to open architectures with interface standards, as described above, is 
instructive. Through the 1970s, computer manufacturers saw their financial interest in signing 
customers up to their proprietary architecture. With the development of the microcomputer, and 
the commercial development of DOS as a proprietary architecture with an open API, the market 
began to shift. Software developers began to develop a wide range of applications for the open 
API, and buyers wanted to be able to exploit this software. Competing proprietary architectures, 
even technically superior ones like the Macintosh, struggled in the marketplace because the users 
demanded access to the wide range of independently developed software. This process of 
standards extended to information exchange protocols such as hypertext markup language 
(HTML) and Structured Query Language. The process of opening the architecture is continuing; 
if current trends continue, the LINUX system, which has open source code as well as an open 
API, will overtake Windows NT as the most popular server system in 2001. 10 DoD lacks the 
discipline of the marketplace and must implement processes that provide the standards, the 
common services using them, and the incentive to choose them in specific systems over a set of 
slightly better optimized stovepiped solutions. 

3.3.5.3 The Current DoD Interoperability Approach 

IERs have become the fundamental basis for defining and assessing interoperability in DoD 
systems. CJCSI 6212.01B defines a process as summarized in Figure 3-5. The three key events 
are (1) certification that the relevant requirements document (Mission Need Statement, 
Operational Requirements Document, or CRD) adequately addresses interoperability; 

(2) certification that the interoperability requirements documented in the C 4 I Support Plan 
(C 4 ISP) via the IER matrix and set of system descriptions are supportable over the GIG; and 

(3) certification that the results of system test and evaluation prove that interoperability 
requirements are satisfied. Those IERs designated as “critical, top level” define an 
interoperability KPP that is a mandatory item for a decision to proceed at major acquisition 
milestones. They thus take on an importance far beyond engineering the interactions among 
systems. 


10 Briefing to the Summer Study by Walker White, ORACLE Corporation, 10 July 2000. 
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Figure 3-5. CJCSI 6212.01B Establishes a Process for Assessing and Certifying the Interoperability of a 

Developmental System 


IERs represent a step forward from traditional thinking that tends to focus on specific systems, 
channels, message formats, and the like when addressing interoperability. An IER is an 
information construct that is independent of the physical means by which the information 
exchange is accomplished. IERs provide the interaction piece of an operational architecture, and 
they establish a basis for both system-of-systems and individual system engineering to find the 
most cost-effective way of servicing warfighter information needs. However, they still force the 
architect to deal with a huge number of pairwise connectivity problems, and for a major weapon 
system the IER matrix becomes unwieldy, involving as many as several thousand individual 
information exchanges among dozens of platforms. As discussed in Section 3.3.8 and in 
Chapter 8, we believe that the JBI is a superior concept that will gradually replace IERs as the 
fundamental definition of how a system or user interacts with the information infrastructure. 

Today, the most visible and controversial element of the DoD standardization approach to C is 
the DII COE, which is a specific instantiation of the Joint Technical Architecture and takes the 
form of a defined software load that creates a standard execution platform. The DII COE, and 
the issues associated with it, have been addressed by a special study team, and the results are 
described in Chapter 8. 
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In addition to these initiatives and those described in Section 3.3.4.2, OASD/C I has defined an 
Outcome-Based Interoperability Process that seeks to link many aspects of requirements 
definition, system acquisition, exercises and experiments, and system engineering tools to infuse 
interoperability into system programs. An early prototype of a Joint C 4 ISR Architecture 
Planning/Analysis System is being tested. C 4 ISPs are now mandatory for all major system 
acquisition programs before beginning engineering and manufacturing development; these 
documents require the development of an IER matrix and the designation of the critical or top- 
level IERs that define the Interoperability KPP. C 4 ISPs have proved a useful vehicle for flushing 
out interoperability problems and helping system designers think about the informational context 
in which their products must operate. We are encouraged by the level of attention that 
interoperability is receiving, but there are as yet few results to show for it in the real world of 
military operations. DoD has far to go to approach the success of the commercial world. 

3.3.5.4 Migration to Improved Processes 

These considerations suggest a number of measures to reform existing processes. We discuss 
them in the areas of operational architecture and requirements, technical architecture and 
standards, and acquisition. 

Improving Operational Architecture and Requirements Definition. This is arguably the 
most important, and certainly the most intractable, area to reform. In study after study, the SAB 
has called for improvement to a process that takes far too long, overly constrains acquisition 
PMs, reinforces traditional stovepipes, and lacks any ability to balance and harmonize the 
various elements of the force. 11 The problem persists. The requirements bureaucracy is 
entrenched, the budget stakes are high, and the imperative to change for the sake of achieving the 
goal of Information Dominance is not yet widely understood or accepted in the operational 
community. Nevertheless, we feel compelled to state the case one more time. 

Since acquisitions are conducted and money is appropriated system by system, there will always 
be a certain system-centric character to acquisition. However, the requirements that drive 
individual programs can and must be cast in the context of the complete force, including joint 
and coalition participation. We need a requirements process that reflects the way we plan to 
fight—joint, netted, interoperable, and, eventually, information-enabled. The C 4 ISR 
Architecture Framework establishes a reasonable process and set of architecture products. Well 
thought-out operational architectures, validated through analysis, experiments, and exercises, 
must have precedence over system requirements and the resulting system architectures. In 
general, a System Program Director should conduct the program under requirements that 
suboptimize the single system because it will be an element of an optimized, integrated, 
interoperable force. For the information-centric CONOPS to work, and for future forces to be 
affordable and supportable, all elements must conform to an architecture that balances and 
allocates functions across platforms and systems. 

This raises the troublesome issue of who should serve as the overall architect and how much 
power over individual system requirements and Service priorities that individual should wield. 

As mentioned earlier, the Joint Staff/J-38 is drafting an initial JOA and supporting set of JMAs. 


11 The November 1998 study A Space Roadmap for the 21 st Century Aerospace Force, SAB TR 98-01 called for, 
among other things, creation of a force structure architect able to, for example, trade off performance 
requirements among space-based and air-breathing platforms. 
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An initial high-level operational architecture for a Joint Task Force has been defined, using the 
C 4 ISR Architecture Framework; this provides a good starting point that must now be fleshed out 
in greater detail. Certainly there must be joint control, and the Joint Requirements Oversight 
Council would seem to be the logical holder of the baton. The Air Force still needs its own force 
architect, both to represent Air Force interests in the joint arena and to enforce the required 
requirements trades across Air Force space, air, and surface systems. Both joint and Air Force 
operational architectures should be closely tied to the JV2020 vision, to the maturing concepts of 
operations of Air Expeditionary Forces, to exercises such as JEFX, and to system-of-systems 
engineering environments such as the emerging JDEP and the Distributed C 4 ISR Simulation 
Network called for in Chapter 8. 

Improving Technical Architecture and Standards Definition. From our consideration of how 
the commercial world succeeds, the following emerge as the overall characteristics of the process 
we seek for moving the current C 2 environment toward a commercial model: 

• Identify communities of interest involving users, developers and supporters of C 2 systems and 
make them the primary drivers in the selection or, when necessitated by unique military 
circumstances, the development of standards. Ensure that architecture and standards are oriented 
to the needs of the system development and operational communities. Ensure, through a process 
of spiral development, experiments, and exercises, that they are fully mature before being 
released for operational use. 

• Tie the definition and refreshment of this standards profile to the spiral process so that standards 
evolve with the systems that use them. Focus the standards activity on the adoption of the 
minimum set of standards adequate to achieved the required interoperability. 

• Provide incentives for the use of standards through economic benefits to contractors and 
economic and operational benefits to users rather than through mandates. Exploit the fact that a 
good standards package reduces technical risk and development cost, allowing resources to be 
used to implement functionality, instead of repeating past experiences where standards mandates 
have consumed huge program resources in the effort to make them work. 

• Make common infrastructure available such that it can be used when it meets system needs and as 
a contributor to interoperability. This will be especially true for common information services, 
including data maintenance, replication, access, and the communications environment. 

• Develop, maintain, and evolve common technical models at all levels of the interoperability 
hierarchy and use these as the primary basis for interoperability. 

• Provide top-level direction, vision, leadership, and enforcement to ensure consistent application 
of the interoperability strategy across organizations and programs. 

As discussed more fully in Section 3.3.7, commercial systems rely heavily on layered 
architectures to maintain compatibility among heterogeneous computing environments, 
accommodate growth, and cope with technology evolution. Different elements in such a layered 
architecture tend to have different growth paths, and DoD needs to find ways to allow such non- 
synchronized evolution at various levels of its information infrastructure. For example, it’s 
likely that the higher levels of the hierarchy in Figure 3-3, involving brain-to-brain 
interoperability between one human-computer interface and another, will change more rapidly 
than the lower levels, where legacy systems that cannot be instantly replaced will continue to 
provide the physical and messaging layers. 

Open architectures that allow individual layers to be integrated or modified with minimal cost 
will be essential for DoD to take advantage of available commercial technologies in a timely 
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manner. Open architectures have other advantages, as well. The less vertically integrated a 
system is, the less specialized it is. Although many physical layer implementations are very 
unique to DoD systems, horizontal integration increases the opportunity for integration of 
commercial products, access to multiple vendors for the same product, and multiple uses for 
systems as a result of flexibility in configuration. 

The basic message is that the commercial world views the business of acquiring, connecting, and 
using information systems in a fundamentally different way from that embodied in DoD’s 
processes. Every path to the information-enabled force involves mastering and applying these 
lessons. 

Improving Acquisition. Given that the future battlespace will be defined by an open, scaleable 
architecture, an evolutionary, streamlined acquisition strategy will be needed to enable rapid 
fielding of multiple future system increments. The operational architecture will be crucial as the 
foundation for establishing the constructs for information flow and must be tied to an acquisition 
strategy predicated on meeting EAF requirements. This EAF-based acquisition strategy is a 
significant detour from the current system-based acquisition strategy; however, without this 
change, we will continue to suffer from deficiencies in interoperability and delays in achieving 
the information systems needed to support the EAF. As an example, acquisition of Link-16 
terminals through the JTIDS, MIDS, and JTRS programs is primarily based on each system’s 
individual capability to fund Link-16 on that platform. The timing of these programs is not 
based on the needs of an EAF. As a result, until every system gets around to implementing Link- 
16 capability (10+ years from now), we will have multiple gaps in our key tactical data network. 

Hence the basic reform in acquisition processes involves making interoperability and conformity 
to higher-level operational architecture a fundamental element of acquisition strategy. Many 
individual steps are needed, from better training of PMs and engineers in the problems of 
interoperability and their solutions to more realistic budgeting and planning for the effort needed 
to achieve and demonstrate interoperability. Once more, the real challenge is to break the 
mindset that a given program is concerned only with its own system and charged with making 
that system as good as it can be in isolation from the rest of the world. 

New tools are available to help. The rapid move to simulation-based acquisition, driven by the 
increasing capability of modeling and simulation environments, makes it far more feasible to 
exercise a developmental system in a larger context to support engineering trades and validate or 
refine designs. The JDEP is a good example. Similarly, executable specifications that capture 
system design in the form of simulation objects can be used as a tool for ensuring that end-to-end 
performance in a system is defined well enough to quantify and achieve a specific and expected 
level of military utility. Executable specifications also help with interoperability by ensuring that 
a specific functionality can be reproduced in a different implementation or by a different vendor. 
Tools that define structured approaches for achieving interoperability such as Through Life 
Interoperability Planning (TULIP, see footnote 5) can be and have been used to evaluate 
interoperability and to predict and correct problems. To be most effective, these tools must be 
applied throughout the entire life cycle so that problems can be identified early, while they are 
relatively inexpensive to fix, and so that interoperability can be maintained through the 
application of effective configuration management. TULIP works by adding rigor to existing 
requirements definition, testing, and configuration concepts while emphasizing complete (“brain 
to brain”) interoperability in a common sense approach. 
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All of this will increasingly be applied in spiral development programs. Requirements and 
designs will co-evolve, and functionality will often be delivered to the end users in increments. 
Complex information systems such as TBMCS are likely to continue to evolve over their 
operational lifetimes. The spiral methodology creates opportunities to correct early mistakes and 
to adapt to changing circumstances. Interoperability problems can be tackled in manageable 
chunks corresponding to each performance increment. However, it remains true that 
requirements must fully account for interoperability and must be predicated on the role the 
system will play in the larger force context. 

To conclude this part of the discussion, we want to point out that from both interoperability and 
programmatic standpoints, the Air Force must take on the challenge of both “requiring and 
acquiring how we fight.” The first “spiral” of this change is to migrate from a system-centric to 
a network-centric capability wherein we have the full compliment of necessary systems 
sufficiently networked to support EAF operations. This will require actions such as providing 
for centralized program elements (PEs) that support information systems (for example, a Link-16 
PE) and then adjusting fielding plans and funding to support a fully capable EAF. This is a 
critical step in that it is the first major transition away from the historical system-based planning 
structure. Once that step is taken, the ground will be prepared for migration to the full JBI. 

3.3.6 Integration of Operational and Technical Interoperability 

In the preceding section, we stressed that technical and operational strategies for interoperability 
must be supported by effective implementing processes. Now we turn to the steps necessary to 
ensure that the technical and operational dimensions are properly harmonized and mutually 
supportive. As we have stressed throughout this chapter, interoperability is about providing 
warfighters with the technical means to realize the operational concepts of Information 
Dominance. To achieve true interoperability we must have a shared understanding of the 
situation among all the participants involved in a particular activity. This understanding must 
envelop the strategic, operational, and tactical perspectives, depending on the participant’s 
function in the operation. Thus interoperability transcends the technical perspective and requires 
that operational doctrine and concepts, procedures, acquisition programs, and policies are tightly 
integrated within the Air Force, across the Services, and with our allies. 

3.3.6.1 First Steps 

Recent operational experience has shown that the fluidity of the operational situation demands 
enhanced ability to dynamically respond to rapid, significant changes. Technological advances 
are exponentially increasing our ability to collect and share data. However, that is insufficient. 
Since much of that data is acquired in ways that are not directly intertwined with our operational 
and tactical environment—always joint, often combined—we are not able to effectively 
synthesize the data into information. Thus we cannot develop the shared understanding 
necessary to take full advantage of our current capabilities. We may one day find that an 
opponent who has properly merged the technical and operational aspects of interoperability has 
the advantage in combat. 

Since we want to tie our effort to bettering our operational capabilities, and because our national 
security strategy, related policies, and doctrine are relatively static, we can begin there. The Air 
Force has made great strides over the last few years with its doctrine development, but much 
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important work remains—for example, a publication that synthesizes current doctrine and tells 
the JFACC how aerospace power should be employed at the operational level. 

The translation of that doctrine into CONOPS to support the C 2 of theater operations is in its 
infancy. We have earlier addressed the need to reform our processes for requirements 
formulation and system acquisition. The new requirements paradigm must closely couple 
technology with concepts for employing that technology to enhance operational capability. That 
coupling must be evident throughout the development and deployment cycle. Therein lies the 
motivation for a spiral process. 

One possible construct for this integration is suggested in Figure 3-6. In the current paradigm of 
requirements and acquisition, operational deficiencies are derived by analysis of missions and 
forces, translated into system requirements, and implemented as a program. A typical “big 
bang” acquisition seeks to satisfy the full requirement at the conclusion of the development 
process. The right side of the figure shows how the spiral development process can be mated to 
the top-level derivation of CONOPS from national military strategy. Then operational concepts 
are used to formulate the operational view of a new system, and the iterations of the spiral allow 
the CONOPS, concept, and design to be incrementally refined and implemented. In this way, the 
operational dimension and the evolving technical solution can be kept consistent and evolved in 
parallel to an acceptable functionality for delivery to the user. 



Figure 3-6. The Traditional Linear “Big Bang" Approach to Delivering Military Capability Should Evolve 
Into One Linking the Development Spiral to Refinement of CONOPS and Concepts 

The work of the AC2ISRC in this area is essential in the spiral paradigm. For that work to be 
most useful, however, it needs to be expanded to address joint and coalition operations. The 
AC2ISRC should team up with representatives from the Army and Navy in the very near term. 
Organizations such as the Army’s Training and Doctrine Command and Communications and 
Electronics Command, the Navy’s Naval Warfare Development Command, and the Marine 
Corps Warfighting Laboratory seem to be key organizations to effect this refinement. This effort 
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is critical to shaping the development, deployment and operation of Air Force C systems and to 
effectively training the warriors who will use them. 

These operational concepts should be chosen to effectively cover the likely set of future 
operational environments, as opposed to an exhaustive set. The chosen set of operational 
concepts should then drive the development of an appropriate operational architecture that will in 
turn support the development of the necessary system views to support force structure and 
system developments. These will then provide a basis for policy makers, developers, and 
operators to share a common understanding of 

• How system capabilities will support the planning and execution of operations 

• New operational opportunities afforded by new technology and related systems 

• How to operationally test and certify the sufficiency of the systems 

• How to interact to further enhance system functionality through development spirals 

33.6.2 The Context 

Since these products will be tremendously complex (and will evolve as a function of the 
insertion of refinements—enabled by technology enhancements to operational concepts), to be 
truly useful they will need to be captured using knowledge management technology. This will 
be helpful in two ways, because in addition to helping the developers, the knowledge developed 
during the development of the products will also be important to the people who actually use the 
systems that result in planning at the strategic, operational, and tactical levels, and in executing 
operations. 
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We must now turn to another dimension of the interoperability challenge—the technical 
perspective. Here we begin to describe the relationship between the decision space shared by 
operational commanders and other decision makers, the information and data that they require, 
and the communications and networks foundation on which the process stands. Figure 3-7 
depicts the end-to-end interoperability construct for decision support. This is, of course, merely 
an expansion (although an important one) of the layered interoperability construct in Figure 3-3. 

In the long term (5 to 15 years) we can anticipate the emergence of technology that will allow us 
to incrementally automate the knowledge formation layer. Even though it is possible to assist 
commanders and other operational decision makers with computerized decision support systems 
based on Bayesian logic and probabilistic estimates, shared understanding will be the limit of 
achievable information support for the foreseeable future. However, even this technology has 
the potential for tremendous (perhaps order-of-magnitude) reductions in decision cycle times. 
This will be true even though we can anticipate that the available information will grow 
exponentially. The Defense Advanced Research Projects Agency, the Service laboratories, and 
industry are investing in these areas. We must continue those investments, and AFRL/HE and 
AFRL/IF should take the lead in sponsoring and encouraging work on information models (see 
Chapter 8) to focus the inference engines and other techniques being pursued. 

In the mid-term (3 to 7 years), automation of data integration into information will be enabled by 
technology that is emerging today in laboratories, system centers, and industry. This technology 
will significantly reduce the current 72-hour ATO battle cycle so that we can more effectively 
support dynamic targeting as well as the Army’s and Navy’s 24-hour battle cycle targeting 
requirements. It will also allow us to more closely couple and enhance the effectiveness of 
information exchanges with our coalition partners. AFRL/IF and ESC should team and add 
emphasis on the Adaptive Sensor Fusion program and migrate the best of breed into the C 2 
environment annually. This effort should be focused consistent with the information model 
described in Chapter 8. The progression just described is sketched in Figure 3-8. 
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Figure 3-8. The Progression, as Technology Advances, from Data to Understanding 


Once more we note the vital importance of shifting our focus from platform-centric to network¬ 
centric, and eventually to information-centric operations. As communication networks have 
become more widely deployed, the opportunity for enhanced cooperation and coordination 
among the C 2 elements is becoming real. Over the past few years, the concept of network¬ 
centric operations has become common. Applications are increasingly able to communicate and 
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coordinate by exchange of information through common networks. Now the evolution of 
communication and computing technologies has resulted in a new opportunity, that of 
information-centric operations. Concepts such as the JBI are rooted in the idea of having a 
“common distributed and virtual information environment” accessible by all of the systems and 
people engaged in operations. 



Figure 3-9. The Evolution from Platform-Centric to Information-Centric Operations 


Figure 3-9 depicts the evolution of the integration of C 2 system functional areas into a C 2 
enterprise. When systems were developed as independent platforms, communications between 
them was, at best, done with dedicated links. As networks developed, the independently 
developed C 2 applications and modules were able to exchange information through a common 
network. However, in both the platform-centric and the newer network-centric approaches, the 
systems and their associated software applications generally “owned” their associated data. 
Information was exchanged between applications, rather than viewing the information as the 
common integrating aspect. 

The information-centric approach attempts to fundamentally shift the paradigm. Recognizing 
that interoperability and integration of C 2 functional areas into a C 2 enterprise requires the ability 
to share and mutually understand knowledge, information, and data, the information-centric 
approach starts with the premise of information primacy. The prime focus is the information 
architecture and model to enable different command elements to operate in a coordinated 
manner. This is enabled through the common information substrate. Applications, while 
designed to provide the commander and staff with the ability to use the information as needed, 
are explicitly designed to operate on the common information objects—storing, processing, 
manipulating, and accessing them as needed. 

Interaction between C functional elements is then implicit. Since they are operating on the same 
information objects, when an information object is created or modified by one element, other 
elements have immediate access to the object. The information substrate provides the 
mechanisms (such as publish/subscribe) to notify the C 2 elements and associated applications 
when new or modified information objects of interest are available. 

3.3.6.3 Bringing It Together 

Finally, we are in a position to discuss how it should come together. The technical perspective 
arises from the application of technology to produce shared understanding and the basis for 
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collaboration and cooperation among warfighters. The JBI will be the key enabler of the 
essential information-centric thrust toward force-wide interoperability. Figure 3-10 suggests the 
way progressively higher levels of cognitive support to commanders and their forces can be 
thought of as knowledge, information, and networking environments. The operational 
perspective, then, arises from the improved CONOPS that are enabled by this information 
infrastructure and evidenced in reduced decision timelines, superior access to timely and relevant 
information at all echelons, and the ultimate outcome of operational success in the form of 
mission accomplishment, survival of friendly forces, minimum collateral damage, and maximum 
efficiency in applying force to achieve military objectives. 
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Figure 3-10. Technical and Operational Dimensions of Information-Centric Operations Come Together in 
Networking, Information, and Knowledge Environments that Support Warfighters at All Echelons 
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Figure 3-11. Demonstrations, Experiments and Exercises Are Key Elements of Integrating Operational 

and Technical Solutions to Produce New Capability 


The fusion of emerging technologies and the new CONOPS they make possible will often 
involve three related but distinct kinds of activities that progressively establish the feasibility and 
utility of a new concept and of the corresponding new system or systems. These are technology 
demonstrations, experiments, and exercises, and they are not uncommonly mixed up. It’s 
important to keep them straight, because each plays a particular role. For present purposes, we 
define them as follows: 

• Technology Demonstration: a limited deployment of a new or improved technology, system, 
architecture, or procedure to provide information and insight concerning the maturity and utility 
of candidate approaches to enhance military capability 

• Experiment: a limited deployment of new systems, architectures, or procedures in a meaningful 
operational context to evaluate their utility, compare alternative concepts, refine requirements, 
and support operational and acquisition planning 

• Exercise: a limited deployment of new and existing systems, architectures, and procedures with 
the involvement of operational personnel to validate their readiness for use and support training 
and other preparations for early introduction of new capabilities into the force 

An exercise tries to emulate the real world operational environment and place realistic stresses 
on the concepts or equipment being exercised. It is intended to get as close as possible to real 
operations. In some sense, exercises provide the military with a substitute for a commercial 
market as a testing ground for alternative futures. An experiment, by contrast, is aimed at 
answering a set of questions about new concepts and systems. If hoped-for results are not 
achieved, the experiment is not a failure but rather a source of valuable information about 
previously untested ideas. Finally, a technology demonstration provides a channel for 
technology users to interact with possible customers and show the kinds of capabilities that 
emerging technology may make possible. Figure 3-11 is a somewhat idealized flow from 
proposed technology and concepts to fielded systems that indicate the place of each of these 
events. 
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Improved interoperability, and, in the larger sense, improved military capability in general, result 
from the marriage of new operational concepts and the technical means to realize them. The 
vision of robust, flexible, end-to-end interoperability, leading to true “brain to brain” cooperation 
and shared understanding, will become reality in the JBI and is the essence of information- 
enabled warfare. 

3.3.7 Layered Architectures 

In this section, we continue and expand the discussion of applying the strategies that have proved 
so successful in the private sphere to attack interoperability problems in military C 2 systems. 
Architecture is the foundation and enabler of C 2 and is thus a thread running throughout this 
Study. One of the central principles that underlie the success of the Internet and, in general, the 
approach of commercial systems to interoperability, is the use of layering in the architectures of 
networks and nodes. Layered structures provide successive abstractions from implementation 
details and establish broadly useful interfaces to enable processes to interact. 

In the course of the study, we have identified and investigated a number of other technical issues 
that are closely related to the JBI. These include information modeling and other aspects of 
establishing a shared information environment. Chapter 8 of this Volume contains a focused 
discussion of these matters and a recommended path to realize the information technology 
foundation of the JBI. Here, we address the general topic of layered architectures and their role 
in implementing highly interoperable information systems. 

3.3.7.1 Commercial Layered Architectures 

The layered architecture of the Internet makes the ready interoperability of the World Wide Web 
possible. It also provides a wide range of benefits to the commercial world. For example, it 
makes possible the creation of Web-based businesses. A properly layered architecture would 
provide numerous benefits to the Air Force, some of which are described below. The Air Force, 
and DoD in general, should adopt a layered approach to communications architecture. It is 
important to understand how the civilian system is structured, and how the benefits flow from 
that, in order to understand how the Air Force, and DoD as a whole, should structure their 
architecture and what benefits can be expected. 
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Figure 3-12. Commercial Layered Architectures Point the Way to Interoperability in C 2 

The layering on the commercial side is represented by the left-hand side of Figure 3-12. The 
first column represents the layering of the Internet. The bottom layer contains the physical 
connections over which the data flows. It includes phone lines, microwave links, and fiber. The 
second is the equipment and protocols to send bits over the physical layer. The top two layers 
describe how data are incorporated in packets and switched from computer to computer reliably. 
These layers describe the Internet, and for the first two decades of its existence, the Internet 
functioned primarily using these layers. In those days, Internet users connected to a remotely 
located computer, logged on, and used the resident software. The transformation between data 
and information was done on the hosting computer. Thus, what was supported was point-to- 
point communications. In effect, the Internet replaced the phone company network. There was 
also limited, low-level file transfer, but conventions on the format and meaning of data were 
settled on a point-to-point basis. There was no thought of an “Internet-based business.” Because 
the architecture was properly layered, the Internet survived several generations of changes in the 
physical layers and the computers implementing the data links, and the evolution of TCP from 
earlier transport protocols. Each layer could evolve at its own pace without upsetting the other 
layers. Furthermore, multiple generations of each layer could coexist and interoperate. This was 
held together by the relative stability of the IP layer, and to a lesser extent the TCP layer. That 
is, provided a user has a computer interface board that can send and receive TCP/IP packets, the 
user can connect to the Internet with the expectation of being able to exchange data with other 
computers, including those yet to be designed and built. 

The next column shows the World Wide Web; this is layered on top of the Internet. The addition 
of data transfer protocols and information models allows the Internet to support the exchange of 
information rather than data. This means that a user thinks of a Web page putting information 
“on the web” and of using a browser to pull information “off the Web.” Even though all the 
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communication actually occurs point to point in the Internet layers, it is sensible to think of each 
system communicating with the Web, rather than with other computers on the Web. There are 
numerous benefits to this approach. One of the most important is that a developer can design 
and test an application that can interact with all the needed computers by making sure that it 
interfaces to the Web. Thus, a company like Amazon.com can develop and run a Web-based 
application allowing customers to find, browse, and purchase books without testing whether it 
works on each Web browser, operating system, or computer that a customer may have. 

Likewise, a vendor can develop a computer or Web browser without testing it against all the sites 
a customer may want to visit. This in turn allows the development of Web-based business 
models and Web-based businesses. The relative stability of the data transfer protocol and 
information models is the key to allowing this to work; anyone can design Web-based 
applications to html and related protocols such as Graphic Interchange Format with confidence 
that they will work with all types of computers and systems. 

3.3.7.2 Layered Architecture and the JBI 

The right-hand side of Figure 3-12 shows what a layered architecture for the military would look 
like. The third column of the chart shows a connectivity structure. The requirements for this 
structure differ from those for the Internet in that it must be secure against physical and 
electronic attack, must support real-time communications, and must interact at high bandwidth 
with highly mobile platforms such as combat aircraft in flight. The network layer of this will 
probably be based primarily but not entirely on IP, and the physical layer will include wires, 
fiber, radio waves, satellite communication (SATCOM) channels and so on. Large sections of 
the physical layer will be based on legacy systems (for example, SATCOM). A crucial 
challenge will be to organize these legacy systems to provide a connectivity layer with the 
requisite robustness, capacity, and flexibility. 

The JBI will be built on top of this Global Grid in the same way that the Web is built on the 
Internet. If the architecture for the JBI is correctly designed, it will provide two large benefits. 
One is that it will allow PMs to ensure that their platforms and systems will be interoperable with 
all other systems by specifying and testing their interaction with the JBI, rather than individually 
with each platform with which they must interact. The other is that it will enable the 
development of JBI-based C 4 ISR applications. The availability of these applications will permit 
the development of operational concepts for fully cooperative forces. 

The layers can evolve independently at their natural pace. This allows the components of the C 2 
system to keep pace with commercial developments in a manner consistent with acquisition law 
and policy while remaining interoperable with each other and the force elements. The major 
interoperability payoffs will come in the way layered architecture facilitates the development and 
evolution of the JBI. This is explored more fully in the next section. 

3.3.7.3 Interoperability and Security 

A fully interoperable force is vulnerable to information warfare attacks on its C 4 ISR systems. 
These can take many forms, including physical attacks on its links, jamming of links, attempts to 
insert false information into RF links, the use of captured equipment to insert false information, 
and attacks by agents within the system. The more interoperable the system, the greater the 
effect that bad data can cause. The periodic virus “epidemics” on the Internet are an example. 
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In general, the Air Force does a good job of protecting its links from attack and jamming, and the 
use of encryption impedes both eavesdropping and the insertion of false information over links. 
However, there are two areas that merit attention. One is to ensure that the Air Force C 2 system 
degrades gracefully when the connectivity bandwidth is reduced by physical attack or jamming. 
The Army Enterprise Architecture provides a good example of this. The other area is to make 
sure that the layered architecture contains adequate security provisions to limit the spread of bad 
information inserted using equipment captured by inside agents and to remove it as efficiently as 
possible. 

3.3.8 Interoperability and the JBI 

Over the past 3 years, the SAB has developed and refined the JBI as the recommended goal 
toward which all C 4 ISR systems should migrate. 12 The power of the JBI concept is especially 
notable in the area of interoperability. This can be seen most clearly by comparing the current 
situation, where interoperability is defined and worked through the IER matrix, with what will be 
the case once the JBI is implemented. 

The idea of the IER represents a major advance over earlier ways of looking at interoperability. 

It substitutes an information construct for the older view based on specific channels, links, 
terminals, and message sets. An IER can be mechanized through any link or channel that 
satisfies its timing, data exchange, and security requirements. It is thus a great step toward 
openness and an information interface approach. However, the sheer number of IERs and of 
platforms and systems among which they must be defined makes this still a very awkward and 
inefficient way to specify, implement, test, and certify interoperability. Any given C 4 ISR or 
weapon system is likely to interact with dozens of other systems and to require thousands of 
IERs, as recently prepared C 4 ISPs illustrate. Each pairwise relationship among platforms creates 
an interface that must, in principle, be verified. The C 4 ISP prepared for the Joint Strike Fighter 
(JSF) documents several thousand IERs, some of which specify 50 or more other platforms and 
systems with which the JSF must exchange information. Those IERs that are critical—about 70 
in the case of JSF—involving dozens of platforms, must be tested by JITC before the JSF can be 
approved for production. This effort can only ensure that the JSF is interoperable with those 
platforms known to the writers of the C 4 ISP. Since the JSF, if successful, will be operated by the 
Air Force and other Services for many years after the C 4 ISP is written, the initial set of platforms 
is likely to be only a fraction of those with which the JSF must interact over its service life. 

Thus, despite the large effort to compile the IERs and then to develop and test them, 
interoperability of the JSF will periodically be a problem for the Air Force as new platforms 
come on line. 


12 SAB report, Information Management to Support the Warrior, SAB-TR-98-02, December 1998; SAB report, 
Building the Joint Battlespace InfoSphere, SAB-TR-99-02, December 1999. 
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Figure 3-13. The JBI Greatly Simplifies the Specification and Assessment of Interoperability 


This contrasts sharply with the situation in a world with a layered JBI architecture. The 
interoperability requirements are now to provide a set of data links and other channels to ensure 
connectivity to the JBI, and to ensure correct transmission, reception, and processing of 
information according to the JBI information model. While this last requirement will be more 
complex than any single current IER, it will be far less complex to deal with than a collection of 
thousands of them. Interoperability testing is simplified because it can now be done with a 
single JBI instantiation rather than with a multiplicity of platforms. Furthermore, future 
interoperability with new systems is assured, provided they similarly conform to the JBI 
interface. Figure 3-13 highlights the difference. 

With the JBI, the same physical events may occur in executing an information exchange as with 
today’s platform-to-platform view, but the logical process is completely different. In the JBI, the 
plethora of IER interfaces reduces to a single, albeit very complex, interface between a platform 
and the InfoSphere. Interactions with the external environment via the JBI are accomplished 
through publish-and-subscribe mechanisms that are far simpler to deal with than hundreds or 
thousands of specific information exchanges. The responsibility for the rest of the process, from 
connectivity among platforms to consistent treatment of information, is transferred to the JBI. 

The transformation layer (implemented with “fuselets”) around the central object repository 
facilitates the definition and implementation of this interface to a legacy or future system. Now 
the KPP becomes implementation of the single JBI interface. This, in combination with 
enhanced access to diverse information services, makes the JBI the fundamental solution to the 
technical aspects of interoperability. 
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3.4 Recommendations 

The emphasis of this study has been on near-term actions to significantly improve Air Force C 2 
in the next 5 years. In the area of interoperability, most of the recommended actions will begin 
to pay off in this timeframe, but also will entail fundamental changes in processes, systems, 
facilities, and other things that will take longer to complete. We have spent many years getting 
ourselves into an interoperability quagmire, and it will take a while to get ourselves out. A 
number of interoperability-related recommendations are contained in Volume 1 of this Study 
report. The panel recommends the following additional actions, grouped by major areas of 
interoperability problems. 

3.4.1 Near-Term Interoperability Corrective Actions 

3.4.1.1 Specific Interoperability Problem Fixes 

Task AC2ISRC, working with related organizations such as the Commanders in Chief 
Interoperability Program Offices and the Joint C 4 ISR Battle Center, to identify specific 
interoperability problems such as those cited in Section 8.3.2. The list should be prioritized such 
that problems correctable by simple technical changes, corrections to TTPs, or other inexpensive 
measures are flagged and given emphasis for quick attention. Task AC2ISRC to collect and 
analyze interoperability problem reports and task all field organizations to report such problems 
to the Center. 

3.4.1.2 Coalition Interoperability Focal Point 

Establish an Air Force focal point to coordinate policy, strategy, and actions involving C 4 ISR 
interoperability with allies. Specific actions include: 

• Define a process for addressing coalition interoperability problems, including linkage to the Air 
Force POM and budget development process, to ensure that proper priority is placed on them. 

• Explicitly address allied roles in warfighting plans, including capabilities that complement U.S. 
forces and guidance for allied C 4 ISR investments. Establish warfighting contexts that clarify 
national roles and policies and whether interactions will be based on alliances, ad hoc coalitions, 
or bilateral agreements. 

• Coordinate allied participation in exercises and experiments, including definition of exercise and 
wargame content that provides a sound basis for exploring coalition interoperability issues and 
operational roles. 

• Maintaining continuity in U.S. positions and representation in solution of protracted issues. 

• Coordinate foreign military sales activities that bear on coalition interoperability. 

3.4.2 A Framework for Interoperability 

3.4.2.1 Centralized Coordination of Interoperability Requirements and Activities. 

As part of the overall centralized coordination and control of C , establish a process and appoint 
an Office of Primary Responsibility to oversee the development of interoperability requirements 
and to direct appropriate actions to resolve interoperability shortfalls. Specific actions include 

• Vigorously support the development of Operational Architectures (OAs) and apply the DoD 
C 4 ISR Architecture Framework as an intrinsic element of requirements definition and validation. 
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• Move to an architecture-driven requirements model and process. Insist that emerging OAs 
provide implementable guidance for developing individual system interoperability requirements 
and that compliance with these be made a fundamental condition for programs to proceed. 

• As the JBI matures, migrate the focus of C 4 ISP development from “Networthiness Certification” 
to “JBI Certification.” 

• Challenge and oppose platform-centric thinking and decisions that inhibit interoperability. 
Require, as part of system requirements analysis and validation, that individual system 
requirements be justified in the context of the overall force of which the system will be an 
element. 

• Establish a focal point for modeling, simulation, and analysis (MS&A) to ensure that tools and 
databases used to work interoperability are developed, maintained, and made available and to 
oversee validation and verification. 

• Coordinate emerging C 2 architectures, especially for the JBI, with other Services and with allies. 

• Coordinate architectures, system requirements, procedures, and other aspects of interoperability 
with other Government entities (Department of State, the Federal Emergency Management 
Agency, etc.) and with NGOs with which the Air Force works during natural disaster responses, 
humanitarian operations, etc. 

• Coordinate the planning, objectives, participants, and products of exercises, experiments and 
demonstrations to obtain maximum data and insight for the continued refinement of architectures, 
system requirements, and interoperable TTPs. 

3.4.2.2 DoD-Wide Information Services Process and Information Repository 

Work with DISA and the other Services to establish an Information Services process as part of 
both near-term actions and migration to the JBI. Specific actions include 

• Define and validate a taxonomy of joint and coalition warfighter information needs; exploit 
C 4 ISPs, existing data models, and other sources; implement Service, joint and coalition doctrine; 
and establish a process to refine the taxonomy over time. 

• Define the characteristics of the JBI information repository (object schema) as requirements for 
the information model and define a process to migrate current models to the JBI objective; 
characteristics include metadata standards and repositories, metadata definitions for model 
elements, segmentation and hierarchy, transformation and traversal engines, methods for 
incorporation of legacy and local data bases (wrappers, translators, etc.), and abstraction 
mechanisms. 

• Direct Air Force Space Command to participate in JBI development and to examine the emerging 
JBI architecture for implications for network defense and other aspects of information operations. 

• Establish a process to select, develop (where necessary) and refresh standards for metadata, 
publish/subscribe, and other attributes of the JBI information repository and services. 

• Coordinate with individual programs (GCCS, GCCS-AF, TBMCS, the Deliberate Contingency 
Action Planning and Execution System, JMPS, etc.) to migrate their information models and data 
repositories to the JBI. Specifically, direct actions and provide funding to web-enable and 
Extensible Markup Language-enable legacy and developmental C 2 systems. 

• Define and fund development of needed common infrastructure. 

3.4.23 Architecture and Standards for Interoperability 

Take specific steps to define and implement the architectural foundation of an Internet-like JBI, 
including 
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• Direct Air Force Materiel Command (AFMC), through ESC, to require layered architectures for 
C 4 ISR systems, especially the JBI. Facilitate communities of interest, in the Air Force, with the 
other Services, with allied nations, and with the private sector, with support funding as 
appropriate, to define standards, architecture, and common infrastructure and to articulate their 
proper application and benefits. Use these communities of interest as the vehicle for selecting 
and evolving a minimum required set of standards to define each layer. 

• Make the incremental development and refinement of the JBI information model a core element 
of the Air Force C 2 program as a whole and of the spiral JBI development in particular (See 
Chapter 8 for additional details). 

• Direct AFMC, through ESC and AFRL/IF, to emphasize the Adaptive Sensor Fusion program 
and migrate the relevant results into the C 2 environment annually. This should be linked to the 
evolution of the JBI information model, which includes processes for data aggregation and 
fusion. 

3.4.2.4 Facilities and Procedures to Evolve an Interoperable Force 

Create a Distributed C 4 ISR Simulation Network environment and accompanying procedures for 
hosting, evaluating, developing, and exercising interoperable C 4 ISR systems. Specific steps 
include: 

4 2 

• Establish a network linking primary C ISR sites, such as the experimental C facilities at Langley 
and Nellis AFBs, the CUBE at Hanscom AFB, the C 2 TIG at Hurlburt AFB, the TACCSF at 
Kirtland AFB, and possibly others. Establish procedures and provide funding to use this network 
to refine TBMCS, support Distributed Mission Training, participate in exercises and wargames, 
and in other ways support the fastest possible transition to information-centric operations for the 
EAF. 

• Participate in the JDEP, including appropriate linking of the Air Force C 4 ISR network just 
described with similar networks of the Army and Navy. 

• Direct ACC, the AC2ISRC, ESC, Air Force Operational Test and Evaluation Center, AFRL, the 
TBMCS program, and other key players in joint and coalition interoperability to vigorously 
pursue contacts with appropriate Army, Navy, and allied organizations and activities to promote 
interoperable architectures and systems and compatible TTP. Include the specific problems and 
issues documented in Section 8.3.4, such as the disconnect between the current ATO timeline and 
Army needs for short-notice target notifications to attack helicopters. 

• As part of the workup to a deployment vulnerability window, require the participating units, 
including the AOC staff, to undergo interoperability training and pass an evaluation. The C 4 ISR 
network or JDEP could be used in a distributed training mode to support this. 

3.4.3 Interoperability in Acquisition and Testing 
3.4.3.1 Interoperability Across the Acquisition Process 

Ensure interoperability is embedded in all phases of system acquisition. Specific actions include 

• Define and enforce appropriate interoperability content in the documentation for every 
acquisition milestone. 

• Explicitly account for interoperability in program and contractual documents (Single Acquisition 
Management Plan, Statement of Objectives, Test and Evaluation Master Plan, etc.). Develop 
explicit interoperability content at all levels of the hierarchy defined in Figure 3-3 in the 
definition of outcomes of individual spirals. 
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• Work with JITC, Joint Staff J-6, and others as appropriate to develop and refine interoperability 
testing and evaluation methods, including live testing, system integration laboratory tests, and 
MS&A. 

• Exploit proven tools and methodologies by facilitating their incorporation into system 
engineering environments and by requiring contractors to define and employ mature 
methodologies for dealing with interoperability; make this capability a source selection criterion. 

• Where appropriate, require interoperability assessment of developmental systems using the 
environment described in Section 8.4.1.4, as a central element of simulation-based acquisition. 

3.4.3.2 Interoperability Working Groups 

Direct the establishment of appropriate Interoperability Working Groups for acquisition 
programs to provide the forum in which common issues beyond the control of individual 
programs can be surfaced, defined, and resolved. 

3.4.3.3 Development of TBMCS and JBI 

Take actions to achieve the fastest possible fielding of required C 2 capabilities, with TBMCS as 
the near-term focus and JBI as the overall strategy. Specific actions include 

• Host TBMCS on the distributed environment described in Section 8.4.2.4 and evolve it to achieve 
the required C 2 functionality for the EAF. 

• Accelerate the development of the JBI, including the key actions described in earlier 
recommendations and using the distributed environment and results of demonstrations, 
experiments and exercises. 

• To focus JBI development, select an important immediate problem and make it the basis for 
initial JBI functionality. We suggest that this problem be the targeting of a time-critical target 
such as a pop-up surface-to-air missile system. The corresponding JBI prototype should include 
both national and theater sensors such as Rivet Joint, U-2, and Global Hawk, with reachback to 
national intelligence sources, a Battle Command Center, and strike aircraft. If this is begun 
promptly, a demonstration as part of JEFX 01 is possible. 

3.5 Conclusion 

There are many reasons that the “fog of war” can dominate the battlespace. The right 
information, delivered in a timely, consistent, and efficient manner, may often succeed in 
clearing the fog. Three situations need to be considered: First, given that the ISR needs are met, 
and unambiguously transmitted to the right action address, efficient and standardized 
interoperability may carry the day. Second, if the ISR needs are not met, interoperability may 
very well be a secondary issue, as the lack of information may result in no action. In this case, a 
defensive posture may still allow order to prevail, so that operating forces can live to fight 
another day. In the third case, the most destructive result could occur when the wrong 
information is passed, or sent to the wrong people. This could mean disaster to an otherwise 
dominant force. Lack of adequate interoperability may cause conflicts or fratricide in strike 
execution, late delivery of essential information, and asynchronous or faulty command action. To 
avert such a situation, unambiguous, efficient interoperability must occur. This is a complex 
problem, for which a solution is absolutely essential to the effective prosecution of warfare. 
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Appendix 3A 

Interoperability Panel Charter 


The Interoperability Panel (IOP) will examine both the underlying technical issues and the 
operational/procedural issues associated with achieving robust interoperability among the 
elements of an aerospace force. The objective of the Panel’s inquiry is to understand the factors 
which enhance or impede interaction among force elements, to identify actions (including 
organizational and procedural changes) which promote robust interoperability, and to 
recommend technology and system developments which will improve the capability of the 
Air Force C 2 infrastructure to respond to the full spectrum of operations likely to be required of 
aerospace forces in the 21st century. Those missions range from humanitarian relief and low 
intensity conflict to major theater warfare and cover the full spectrum of operational elements. 
The panel will exploit relevant results from recent SAB studies, including those dealing with 
Aerospace Expeditionary Forces and Information Management to Support the Warrior, and will 
coordinate closely with other panels, especially those on Technology and Concepts and System 
Definition, on areas of mutual interest; focal points will be established with other panels as 
appropriate. 

The prevailing ideas about jointness and interoperability within the DoD and the Services are, at 
best, inadequate, and, at worst, wrong and counterproductive. It is generally believed that 
“standards-based design” is sufficient to achieve interoperability. This is demonstrably 
nonsense. In general, the seductive appeal of simplistic standardization mandates seriously 
impedes strategies that can actually achieve interoperability. Effective means of coping with 
rapid technology evolution, especially in the co mm ercial marketplace, so as to maintain 
compatibility among defense equipments based on different technology generations are almost 
entirely lacking. Bureaucracies with entrenched interests are limited in their insight into the real 
issues and reluctant to change. The problems with interoperability within U.S. defense and 
international agencies are compounded in the arena of coalition operations. 

Among the specific issues the panel will address are the following: 

• Define the information processes which underpin information superiority in the battlespace and 
the associated technical issues such as 

- A common information model for warfighter interactions 

- Efficient mechanization of data, information and knowledge repositories and approaches for 
sharing their content 

- Effective development and maintenance of information intensive systems 

• Examine the IER constmct as defined in recent Joint Staff publications, as well as associated 
policy and directives, as a basis for achieving robust, all-condition interoperability 

• Define the levels of interoperability, including connectivity, communication, and compatible 
(“brain-to-brain”) information and knowledge processes 

• Identify and evaluate technical issues associated with terminals, information environments, 
networks, waveforms, standards, and procedures and changes that can improve interoperability. 
For example, how far will compatibility with the JTRS specification go in achieving 
interoperability among communications nodes? 
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• How should the current DoD C 4 ISR Architecture Framework and supporting documents such as 
the Joint Technical Architecture be evolved to facilitate true, operationally meaningful 
interoperability? 

In keeping with the overall study Terms of Reference, the IOP will address both near term 
(present to 2005) and farther term recommendations to the Air Force leadership. Among the 
areas where immediate action to promote a more connected and interoperable Air Force are 

• Leverage recent and ongoing efforts in multiple programs to define IERs and document 
interoperability requirements in C 4 ISPs 

• Build interoperability content into exercises, experiments, wargames, etc., to refine and validate 
IERs, diagnose and correct interoperability problems, and improve overall requirements in areas 
such as communications capacity 

• Implement the recommendation of the 1998 SAB Space Roadmap Study to establish a force 
stmcture architect with control over system requirements; interoperability would be a key aspect 
of this function 

• Start the development of a Common Architecture Data Model as called for, but not implemented, 
in the DoD C 4 I Architecture Framework; make open, information-based architecture a 
fundamental requirement of the requirements and development processes for all systems 

In short, the Interoperability Panel faces a major challenge in articulating the true problems that 
interfere with interoperability and in formulating actionable recommendations which will, 
inevitably, involve unpalatable organizational, cultural and programmatic changes. However, 
the future of U.S. military success depends critically on information superiority, and recent 
experiences in Kosovo and elsewhere have shown decisively the shortfalls in existing processes 
and programs. The Interoperability Panel will seek to define policy, organizational, technology, 
system, and operational actions that can rapidly close existing interoperability gaps and lay a 
solid foundation for information-enabled warfare in the years and decades ahead. 
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Chapter 4 

Report of the Technologies Panel 
Technology Investment for Future Capabilities 


4.1 Introduction 

The current generation of Air Force command and control (C 2 ) systems is built on a base of 
commercial technology, customized for military functionality. For example, the Theater Battle 
Management Core System (TBMCS) uses a commercial database (Oracle) as its core with 
special-purpose military applications riding on this core. Because of the significant technology 
development investment being made each year by the commercial software industry (over 
$ 1 billion by Oracle alone), commercial advances in information systems are growing at an 
accelerated rate. This situation will enable the Air Force to rapidly field new military 
information system capabilities, such as the Joint Battlespace InfoSphere (JBI), but will also 
place significant challenges on technology deployment within the Air Force’s C 2 structure, 
simply because of the rate of change of technology. As an example, Oracle’s internal cycle time 
from product development to product introduction is normally within a 12-month window. The 
Department of Defense (DoD) acquisition process constrains military C 2 systems to a 
significantly longer development cycle, resulting in the deployment of systems that are often 
built on already obsolete core products. For example, the current release of TBMCS uses a 
version of the Oracle database management system that is over a 100 minor revisions behind the 
current commercial release. 

Due to the large-scale investment in information systems technology by commercial vendors, 
technology, for the most part, is not a barrier to development of Air Force C 2 systems. In this 
chapter an assessment has been made of the available technologies relevant to the C 2 intelligence, 
surveillance, and reconnaissance (C 2 ISR) mission. 

Perhaps the major challenge the Air Force faces is how to leverage the information system 
revolution, fueled by e-commerce, and transition new capabilities into Air Force operations on a 
fast time-line. For the first time since World War II, the Air Force lags behind the civil 
community in application of new—mostly information—technologies and inventions. The Air 
Force has no shortage of good ideas on how to apply technology to solving current problems. 
There is a growing sense of frustration, however, among the operational and development 
community on how to bring good ideas into the operating environment. Very little of the C 2 - 
related technology developed by the Air Force Research Laboratories (AFRL), from the Defense 
Advanced Research Projects Agency (DARPA), or from the Joint Expeditionary Force 
Experiment (JEFX) experiments has yet transitioned into operational C 2 programs. In our 
recommendations we have included a commentary on how the technology transition process 
could be put on a fast-track to speed technology deployments that can improve C 2 ISR operations. 

Leveraging the information technology revolution, which is fueled by e-commerce, to enhance 
C 2 ISR operations will require the Air Force to consider new sources for technology. Historically 
all major C 2 ISR systems have been developed using a prime integration contractor. In our 
recommendations we have also addressed how the Air Force can benefit by reaching out to other 
technology development sources to speed the development and deployment of next-generation 
C 2 ISR capabilities. 
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4.2 Approach and Visits 

The approach selected by the panel for evaluating the availability of suitable technologies for 
achieving C 2 dominance was to request input on relevant technology efforts from technology 
leaders in industry (commercial and defense), from universities and from government research 
facilities including AFRL, DARPA, the National Reconnaissance Office (NRO), the Defense 
Information Systems Agency (DISA), and the other Services. Input was also provided on 
operational technology needs by the Aerospace C 2 Intelligence, Surveillance, and 
Reconnaissance Center (AC2ISRC) and current C 2 programs by the Electronic Systems Center 
(ESC). Finally, the Technology Panel membership was selected to provide a breadth of expertise 
across the technology areas deemed to be most critical to meet the Air Force’s near-term and 
longer-term C 2 needs. Table 4-1 lists the organizations and facilities visited during the course of 
the study. 


Table 4-1. Technology Panel Visits 


Technology Panel Visits 


Hurlbert Field 20-21 March 

AF C2 Vision, Approach & Progress; Maj Gen Perryman 
Roles & Contributions of ESC; Lt Gen Kenne 
C2 as a Weapon System; Mr. Barringer 

Battle Management From Joint STARS-Past & Future; Col Lindsley 
Past, Present & Future Contributions of the AFC2TIG; Col Carr 
USAF C2 Acquisition; Brig Gen Obering 
C2 Battlelab Process, Accomplishment & Plans; Maj Swaney 
JEFX 2000; Col Carr 

Langley/AFC2ISR 10-11 April 

ACC Lessons Learned In Operation Allied Force; Maj Hampton 
AOC as a Weapon System; Col Joe May 

AC2ISRC C2 & ISR 02 POM Campaign Plan 2000; Col Wayne Ranne 
Managing the C2ISR Enterprise; Lt Col Joe Martin 
Tactical Data Links USAF Interests and Way Ahead; Lt Col Mike Balog 
Bridging The Gap: Operational To Tactical Art; Col Steve Callicutt 
Distributed Common Ground System Program Overview; Mr. Donald Walker 
Global Information Grid for the Warfighter; Col Jack Fellows 

ISR Battle Management (ISRBM) Tool Demonstration Update; Lt Col Ginny Tonnesson 

Air Force Experimentation; Lt Col Skip Liepman 

Kosovo Lessons Learned; Gen John P. Jumper 

Theater Battle Management Core System; Lt Col Kevin Damato 

Time Critical Targeting & Real Time Information In The Cockpit; Lt Col David Jones 

The Limitations of Doctrine; Gen John P. Jumper 

NRO/DARPA 16-17 May 

NRO Strategic Thrusts Integration Program Strategy; Maj Gen Dickman 

Corporate System Engineering Function; Mr. Broadwater 

Deputy Director for Military Support Perspective; Brig Gen Crawford 

EMIT Perspective; Brig Gen Sover 

Future System Perspective; Mr. Roche 

Communications Perspective; RADM Fisher 

SIGINT Perspective; Mr. Fitzgerald 

Information Support Strategy; Mr. Mahen 

Airbourne Overhead Interoperability Office Perspective; Col Wheeler 

Strategy Gaming and Experimentation; Mr. Hernandez 

Kosovo Lessons Learned; Col Gill 

NRO Analysis Center Studies; Col Jones 

Collection Concept Development Center; Mr. Gibson 

DDB; Dr Mulari 

Langley/Fusion Briefings 23-25 May 


Rome Labs/ESC 12-15 June 

IF Overview; Mr. John Graniero 
Global Awareness Overview; Mr. John McNamara 
Adaptive Sensor Fusion; Mr. Mike Hinman 
Multiplatform MTE fusion; Mr. Jon Jones 

GMTE - Ground Moving Target Exploitation; Lab Mr. Brian O’Hern 

Dynamic Data Base; Mr. Pat McCabe 

BROADSWORD; Dr. John Salerno 

Joint Targeting Toolbox; Mr. Joe Palermo 

Targets Under Trees (TUT); Mr. Ed Zelnio 

DP&E Overview; Dr. Nort Fowler 

Joint Battlespace Infosphere (JBI); Mr. Rick Metzger 

Effects Based Operations; Mr. Dan Fayette/Dr. Lemmer 

Intelligent Agents; Mr. Jamie Lawton 

JEFX Activities; Maj Bob Marmelstein 

SOF Plan Active Templates; Mr. Dale Richards 

Sensor-Decision Maker-Shooter; Mr. Ken Trumble/Derryl Williams 

Datawall; Mr. Pete Jedrysik/Lt Quant 

GIE Overview; Dr. Warren Debany 

Link-16; Mr. Mark Minges 

SATCOM/CDL Activities; Mr. Walter Hartman 

Airborne Communications (Node and Relay); Mr. Richard Hinman 

MEMS/Ultracomm; Mr. Paul Ratazzi 

Langley/ISR Briefings 21-22 June 

SPAWAR/SWC 26-28 June 

Center OverviewA/ision Brief/Command Center of the Future (CCOF); Tom Kaye 

Commander in Chief for the 21 st Century; Tom Tiernan 

Global Command and Control System; Jack Gerrard 

Cognitive Technologies; Ken Kaufman 

Strategic Decision Making Under Stress; Guy Leonard 

Distributed Collaboration; Lorraine Duffy 

Horizontal Integration and S&T Technology Integration; Don Johnson 

Information Operations Center of the Future; Lee Zimmerman 

Information Assurance Experimentation; Christine St Clair 

Tactical Digital Information Links (TADILS); Janet Bailey 

Common Data Link Management System; Janet Bailey 

TADILS Foreign Material Sales (FMS); Greg Lawrence 

Distributed Engineering Plant (DEP); Dave Andersen 

Real Time Execution Decision Support (REDS); John Me Donell 

Automated Communications Management System (ACMS); Sally Norvell 

Location of GPS Interference; Fernando Escobar 


Summer Study Final Session 10-21 July 

Oracle Corperation; Mike Lennon 

Sun Microsystems, JavaSoft; Timothy Lindholm 

TBMCS Briefing; Mike Charron, Rizwan Jaka, Howard Able 
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4.3 Findings and Discussions 


The Air Force vision of global vigilance, reach, and power requires assured decision dominance 
over adversaries. The Air Force has committed to strengthen the ability of commanders to 
command and control aerospace forces to achieve and maintain this dominance. The opportunity 
exists to harvest a rich and diverse array of technologies, systems, and services to substantially 
enhance the ability of the Air Force to establish and maintain this essential, dominant C 2 
capability. Figure 4-1 summarizes the availability of technologies either from commercial or 
government sources, for providing key capabilities to achieve C 2 dominance. Figure 4-1 also 
indicates the panel’s assessment of how well available technologies are being exploited in Air 
Force C 2 systems. The rationale behind this assessment is included in the following sections for 
each key capability area considered. 
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Figure 4-1. Available Technologies 


4.3.1 Dynamic Planning and Execution 

Implementation of dynamic planning and execution (DP&E) requires a shift in C 2 focus from 
scheduling systems to planning systems. These planning capabilities must accommodate the 
ever-present dynamic and uncertain nature of active operations. Some of the dynamic tasking 
requirements associated with time-critical targeting are described in Appendix 4D. 13 These 
include dynamic tasking of both sensors and shooters. 

DP&E will require changing to interactive, adaptive, dynamic, and closed-loop processes as 
opposed to the open-loop, finite-time-horizon planning approach used in earlier C 2 systems. 


13 Appendix 4D can be found at the end of this Volume. 
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Many of the principles developed for use in dynamic control system design can be applied in 
developing this process. 

Achieving C 2 dominance also requires maintaining an evaluation of the opportunity cost 
associated with real-time reallocation of resources. The dynamic nature of this approach also 
requires that the impact of the dynamic nature of the environment (for example, weather) be 
included in this continuous planning process. In the following sections, our assessment of 
available technologies is provided along with our assessment of how effectively relevant 
technologies are currently being deployed within Air Force C 2 systems. 

4.3.1.1 Commercial Off-the-Shelf (COTS) 

Examples of commercial decision-making tools that appear applicable to many DP&E situations 
include tools used in banking and finance as well as airline and package-delivery scheduling and 
corporate planning. In most cases, however, the military decision-making tasks are more 
demanding and complex than their civilian counterparts in the number of degrees of freedom, the 
scale of the tasks, the temporal dynamics of the environment, the intensity of adversarial 
engagement, and the impact of the outcome. As a result, few COTS technology solutions are 
readily applicable to the Air Force DP&E enterprise beyond general-purpose office automation 
suites (for example, Microsoft Office), some general-purpose analysis tools (for example, SPSS 
and MATLAB), and coordination facilitation tools (for example, Lotus Notes). 

4.3.1.2 Government Off-the-Shelf (GOTS) 

The Air Force, in concert with other DoD organizations including DARPA and the other 
Services, has a steady stream of DP&E research programs and prototypes in various stages of 
maturity. A number of these are on track for operational deployment (for example, the 
Worldwide Aerospace Route Planner, the Joint Defensive Planner, the Air Tasking Order 
Execution Management Reports, and the Joint Targeting Toolbox) and several represent 
emerging capabilities that need to be pushed along the pipeline. Examples include the planning 
and scheduling technologies embedded in the AFRL Information Directorate (AFRL/IF) 
products such as the Advanced Mobility Scheduler and the Campaign Assessment Tool. Still 
further out are capabilities deployable within several years, including the Multi-Asset 
Synchronizer being developed under the Advanced ISR Management program at DARPA, as 
well as knowledge-based planning technology emerging from DARPA’s Active Templates 
program (run by AFRL/IF), the Attack Operations Decision Aid being developed by ESC, the 
AFRL Air Operations Center (AOC) Systems Status Controller and Master Caution Panel and 
Theater Ballistic Missile Reasoner. Many of these prototypes are to be evaluated as Category 1, 
2, or 3 JEFX, or by special Major Co mm and (MAJCOM) exercises including the Air Force 
Special Operations Command (AFSOC) and the Air Mobility Command (AMC). 

4.3.1.3 Deployment 

The deployment of promising technologies into operational use is being delayed due mainly to 
the lack of an environment promoting direct working relationships between the technology 
development community and the Air Force user community engaged in daily practice of the C 2 
operational art. In isolated instances where this relationship exists (for example, AFSOC and 
AMC), rapid concurrent technology development and exercise consistently lead to direct 
insertion into the user’s ongoing acquisition programs. 
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An effective mechanism to realize this leveraged developer-user interaction would be a 
sustained, pro-active C 2 center of excellence co-located with operational users engaged in the 
operational art with network connectivity back to the development activities at AFRL, 

AC2ISRC, and C 2 BL. The emerging JBI Distributed Testbed will have nodes at these locations 
and could serve as the backbone for this connectivity. This approach would enable rapid 
evaluation and real-time technology steering for emerging technology while lowering barriers to 
innovation and insertion. 

4.3.2 Connected, Survivable, Reliable Communications 

Maintaining connected, survivable, reliable communications is essential to achieving C 2 
dominance. The communications systems architecture must be flexible enough to benefit from 
current and future technologies and capabilities and must also provide seamless interoperability 
with numerous legacy systems, including integration and enhancement of the Link-16 system. 
Widespread use of bandwidth-efficient modulation, spread-spectrum capabilities, incorporation 
of higher frequencies, and proliferation of software radios are examples of leveraged technology 
insertion candidates that can enhance robustness to provide connected, survivable, reliable 
communications. The use of commercial communications systems and services is expected to 
become more widespread, and enhanced connectivity to smaller units within a more mobile Air 
Force and interoperability with other Service elements will remain a priority. 

The scope of communications considered here includes intra-system (networked connectivity 
among components of the C 2 system itself) and extra-system communications from the 
networked elements of the system to external users (such as aircraft) and from external users 
(such as aircraft and intelligence sources). 

43.2.1 COTS 

The commercial sector is investing extensively in communications systems and services, many 
of which could be used extensively for Air Force and DoD needs. It is appropriate to recall that 
much of this current investment in systems and services is based on technology initially 
developed as a result of research funded by DoD. Examples are numerous and include 
networking protocols, fiber optic technologies, wireless networks, satellite communications 
(SATCOM), high-power amplifiers, low-noise receivers, integrated circuits, and many more. 
Much of the current investment is fueled by the need for greater bandwidth and is driving the 
installation of fiber optic networks and the development of fiber optic components, including 
wave division multiplexing. Wireless technology is another major area of investment. This is 
being driven by the expanding use of cellular systems and wireless access by a variety of 
personal digital assistants. 

Intra-system communications support the network used by the C system for internal network 
communications. COTS solutions exist for many of these C 2 requirements. COTS networking 
protocols, including Internet Protocol (IP), ATM, and SONET provide connectivity and 
interoperability. Commercially available security capability is sufficient to isolate C 2 networks 
from the secure networks they ride over (for example, secure sockets as used by TBMCS and 
others). Messaging standards are also available, including Extensible Markup Language (XML), 
which are being designed to facilitate networked data transfer between information systems. 
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Extra-system communications are necessary between the C system and the outside world. Most 
of this communication traffic will be carried by direct radiated radio frequency (RF) or 
SATCOM links. Commercial standards for these links, including GSM-3, IS-95, and VSAT, 
exist and are suitable for many DoD C 2 needs. 

4.3.2.2 GOTS 

Current Government communications systems used to provide “anytime, anywhere robust 
connectivity” have generally been unique implementations of COTS solutions. GOTS standards 
exist primarily because the commercial standards do not take into account many unique DoD 
needs, including security, low probability of detection and interception, and survivability. 
Examples of these GOTS standards are numerous and include Link-16, TADIL-J, TADIL-B, 
Common Data Link, TCDL, and others. 

4.3.2.3 Deployment 

Deployment of commercial systems and services for satisfaction of C 2 needs will increase. It is 
also true that continued, sustained investment to satisfy unique C 2 mission requirements must 
continue. The combined commercial focus on near-term technologies and government focus on 
longer-term technologies has resulted in opportunities for government investment that will 
enable unique and unprecedented advances. A number of the most highly leveraged investment 
opportunities follow. 

Programmable and Software Radios. This includes programmable waveforms and 
programmable spectrum usage. The purest form of this is the software radio, which has no 
conventional RF demodulator at all and thus has unprecedented flexibility in modulation and 
spectrum. The Joint Tactical Radio System program is developing a digital radio that will store 
six simultaneous pre-programmed waveforms. Once developed and in widespread usage, this 
technology offers the opportunity to develop and deploy new waveforms and spectrum usage 
algorithms to meet specific jamming and channel capacity challenges. In addition to the 
component technologies needing to be developed, system-level development and integration will 
be challenging. The ability to dynamically deploy these new waveforms and algorithms in near- 
real time will require the development of more adaptable software radios, appropriate transfer 
protocols, and supporting infrastructure and policy. 

Exploiting Commercial and National Satellites. Commercial and national satellites offer the 
opportunity to communicate with aircraft with high bandwidth and low probability of detection. 
Much of the technology needed to do this has been developed, but much work remains to be 
done in designing apertures and systems that are more cost-effective to integrate into aircraft. 
Another high-value development is to design apertures and radios that are more flexible. Even 
though the cost of incorporating a new communications system into aircraft will inevitably 
remain high, this flexibility will allow us to adapt communications systems to reflect changing 
C 2 needs. Additional challenges remain, including system architecture and protection of 
information. A flexible infrastructure architecture is needed that can accommodate the specific 
commercial or national capabilities available in each potential area of operation. Additionally, 
commercial capabilities at any given point in time will vary, depending upon many factors 
totally out of DoD’s control. Achieving this flexibility requires continuing the dialog with the 
national community. It is essential to add a dimension to this dialog, namely to establish a 
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meaningful and sustained dialog with the commercial sector to develop a current assessment of 
commercial systems and capabilities. 

Integrated Network Architectures. This has long been a challenge: Each platform—aircraft, 
satellite, ship, land vehicle, and fixed structure—can be a node in a global communication grid, 
very much like a cellular network today. Significant issues with access control, adjudicating 
usage, and even priority usage of commercial systems in a national emergency all remain. 

Link-16 Follow-On. Even though Link-16 will not be completely fielded for several more 
years, it is already an old technology. Significant enhancements are required to meet even 
today’s requirements. Specifically, link latency must be reduced below 1 millisecond to enable 
new targeting technologies to be employed, the system must be made rapidly reconfigurable to 
allow the addition of assets during operations, and the overall throughput must be increased. 

Integration With Legacy Systems. As we field new systems, we must take legacy systems into 
account. It is generally unaffordable to replace an entire communications infrastructure at once, 
due to the massive investment in legacy terminals. Thus new systems must be fielded in a way 
that allows continued support for older systems during an orderly transition. We need to develop 
more cost-effective ways to do this. 

Bandwidth-Efficient Communications. Bandwidth is already limited today, and tomorrow’s 
C 2 systems will use far more. In a bandwidth-constrained environment we need to develop new 
techniques for packing more data into the scarce bandwidth available. These techniques include 
maximizing frequency reuse (for example, systems such as the Airborne Communications Node, 
Large Aperture Spacecraft, Mobile User Objective System, ACeS, and THURAYA are all 
designed to do this), demand-access multiple-user techniques, bandwidth-on-demand systems, 
and bandwidth-efficient modulation techniques. Finally, exploration of trellis coding or soft- 
coding techniques (the best known is called Turbo-Coding) to reduce required bandwidth will be 
a very fertile research area. 

4.3.3 Information Integration and Fusion 

Combining information to estimate or predict the state of the battlespace, known as fusion (or 
data fusion), is still at a primitive stage. There is no consistent and meaningful definition or 
conceptualization of the “battlefield information state” that the fusion process is intended to 
estimate or identify and that must underlie any meaningful definition of the common operational 
picture. 

While the main focus of fusion and situation and global awareness (S/GA) is upstream from the 
sensors that provide the raw “probes” into the battlefield, a critical role of fusion is to identify 
and quantify sensing shortfalls—that is, areas in which the available information is simply 
inadequate for the production of fused info-products of desired or required quality. The Air 
Force should make sure that the performance assessment portion of the main recommendation 
includes identifying such shortfalls, as well as the associated task of working with sensing 
technologists to identify options for overcoming these information shortcomings. The advantage 
of doing it in this manner is that the value of new sensors is assessed in vivo, as embedded 
capabilities that affect S/GA performance, rather than in isolation. 
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4.3.3.1 COTS 

Commercial industry has developed and is continuing to develop applications to perform data 
mining. This involves defining metadata standards that are critical to the fusion process. 
Regrettably, enough differences exist between the problems being solved in the commercial 
world and the problem of characterizing a time-varying battlespace that there is limited 
applicability. 

4.3.3.2 GOTS 

Some existing fusion and other S/GA technologies contain needed and useful capabilities that 
can be fielded in the near term to provide enhanced C 2 capabilities. These need to be identified, 
cataloged, tested, and quantified in terms of performance and pushed along the transition 
pipeline and ported to the C 2 infrastructure. 

Other existing fusion and other S/GA technologies are not quite as far along as the first set to be 
identified under S/GA-1, but can provide deployable capabilities within 5 years. These need to 
be identified, prioritized, and then acted upon. Since some of these capabilities are being 
developed by other organizations (such as DARPA or other Services), the “action” here must not 
simply involve internal Air Force activity but must also involve either working with (or making a 
case to) DARPA and working with other Services to develop joint capabilities. 

Among the capabilities that fall into this class are the All-Source Track and Identify Fusion 
component of DARPA’s Dynamic Database program, but there are many other possibilities to be 
cataloged and prioritized. Note that while the Air Force has done a very good job of working 
with DARPA in the past—in the area of ground moving-target indication, for example—even 
more can be done if the Air Force strengthens its technology transition pipeline so that, in 
DARPA’s eyes, it becomes a reliable transition path for DARPA technology as well as a trusted 
source for identifying technology needs that drive future DARPA programs. 

4.3.3.3 Deployment 

Only systems that combine small numbers of inflexible types of data are being deployed. As 
more effective multi-source fusion engines become available, a substantially greater deployment 
funding line will be warranted. 

Some fusion capabilities are already (or are on their way toward being) operational in 
contingency theater automated planning system or TBMCS and in systems of other Services (the 
All Source Analysis System, the Tactical Event Systems, and the Joint Maritime Command 
Information System/Global Command and Control System-Navy). In addition, emerging 
capabilities (at AFRL and DARPA) need to be pushed along the pipeline. To be sure, the 
capabilities available do not represent a final or 100 percent solution. However, they do 
represent important functionality and the point of departure for any enhancements. Not only 
should these existing capabilities be ported to the JBI infrastructure, but their capabilities need to 
be codified and quantified. Doing this, however, will require the development of a dearly needed 
discipline, essentially that of providing a “spec sheet” for capabilities. Very roughly speaking, 
what we have in mind here is the equivalent of the specs one finds for electronic components, 
which quantify the requirements or constraints each capability component has on its inputs and 
the resulting quality of the outputs it produces. An example here is track accuracy or continuity 
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as a function of measurement revisit rates, false alarm rates, detection probabilities, and range or 
cross-range accuracies. 


As a related comment, we should point out that one of the impediments to the technology 
pipeline is the resistance to fielding 70 percent solutions: rather than being viewed as providing 
additional capability, developers are criticized for leaving out one particular additional 2 percent 
or another, which diverts effort from getting some capability out to the user and then using that 
as a launching point for enhancements. This represents a change in culture and values in dealing 
with capabilities and also points to the need for a requirements process that neither leads nor lags 
development and deployment. 

4.3.4 Information Assurance 

DISA estimates that there are 250,000 attacks on DoD computer systems every year. Some of 
this activity, when directed against DoD systems, might include information warfare (IW) 
actions to “prepare the battlefield” for future interference with U.S. activity. We can expect 
targeted attacks on DoD systems to increase during hostilities. Both the threat and our 
vulnerability will increase with increasing connectivity among military systems and to civilian 
networks. Thus, vulnerabilities in the networking technology or in any connected system can be 
exploited by anyone anywhere in the world to penetrate and corrupt DoD systems. Another 
source of vulnerability arises from the increased reliance on commercial products. Co mm ercial 
security is neither designed nor intended to withstand IW attacks, and a large number of 
exploitable flaws and attacks on commonly used products are known to a wide community. 
Furthermore, the increased homogeneity that results from the nature of today’s commercial 
computer system marketplace leaves DoD open to attacks that can quickly affect a large 
percentage of its operations. DoD also depends on vulnerable commercial infrastructures such as 
telephone networks that although highly reliable were not designed to withstand IW attack. 

There are numerous risks to C 2 operations. Vigilance is required on the part of system designers, 
implementers, managers, and users to anticipate security vulnerabilities and to address them with 
technical or procedural means. Constant awareness that portions of the system may be 
compromised will help warfighters react appropriately to situations. Backup plans should be 
developed for the most likely compromise scenarios, and warfighters should be trained in these 
procedures. Some of the steps that can be taken to provide information assurance are 
summarized in Appendix 4D. 14 

4.3.4.1 COTS 

To be affordable, Air Force C systems, including protection functions, will be built largely from 
commercial software and hardware computing and networking components. These co mm ercial 
products contain numerous security vulnerabilities, and as they are discovered, these 
vulnerabilities are routinely posted to frequently accessed websites (for example, Bugtraq). 
Attacks are developed against many of these vulnerabilities, and software tools to carry out the 
attacks are posted to hacker. Commercial security products are not built to withstand the 
strength of attack that can be expected for military systems, but to provide a degree of strength 
appropriate for many business operations. Known vulnerabilities in these security products, as 
well as attacks exploiting them, are also posted on the Web. Vendors may respond by issuing 


14 Appendix 4E can be found at the end of this Volume. 
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patches (which may take weeks) or correcting the problems in scheduled new product releases 
(which can take months), resulting in a period of exposure during which procedural workarounds 
must be employed to reduce risk as far as possible. Most system operators may not be aware of 
the discovered vulnerabilities in the products they are using or of the availability of procedural 
workarounds or patches. 

43.4.2 GOTS 

In recent years, DARPA and other agencies have funded research in information assurance that 
has resulted in some promising technologies that should be evaluated for use in Air Force C 2 
systems. Examples include encrypted e-mail, secured protocols, better intrusion-detection 
components, digital signatures on software, early versions of wrapper generation toolkits, 
prototype local intrusion detectors, and a framework for coordination of intrusion detection and 
response. AFRL has participated in the development of many of these technologies and could be 
funded to evaluate them and select the most promising for maturing and transitioning into the Air 
Force. DARPA technologies available for such treatment are summarized in the tables included 
in Appendix 4D. In addition, DARPA has integrated several of these technologies in areas of 
prevention, detection and response, and security management for command, control, 
communications, computers, and intelligence information systems. 

Because of the large shortfall of current security technologies relative to needs, the DoD research 
community is continuing to focus on several areas not being addressed by industry. These 
include 

• Intmsion assessment to distinguish serious targeted attacks on critical systems of high concern 
from other attacks of lesser concern. 

• Technologies for intmsion-tolerant systems, to maximize a critical system’s ability to keep on 
providing service despite successful attack and partial system compromise. Component 
technologies could include intrusion detection, protocols that allow systems to react to detected 
events, algorithms to redirect resources to the most important tasks and whose behavior is 
difficult for an adversary to predict, and techniques for reconfiguring to a state not susceptible to 
the original attack. 

• Technologies to limit an attacker’s ability to carry out denial-of-service attacks. 

• Technologies to allow existing and legacy systems to be retrofitted with some security and 
reliability functionality. 

In addition to these, research is needed in areas of mobile code security, extending the 
capabilities of virtual private networks, and dependability. There is also a need to develop DoD- 
specific solutions for areas that industry is not addressing because there are no common 
commercial analogs—for example in the area of tactical networks. 

4.3.43 Deployment 

The high rate of release of new products and product upgrades means that at any given time there 
may be no common software configuration across Air Force C 2 systems. With each new product 
and product release comes the need to keep up to date on product vulnerabilities and fixes. In 
addition, policy must be generated about acceptable and safe product configurations, and these 
configuration mandates must be monitored and enforced across the Air Force. Failure to do so 
will result in unnecessary exposure to vulnerabilities. In addition, these products have many 
unknown vulnerabilities that will be discovered during their lifetimes. Generally, due to product 
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size and complexity, it is not possible to discover all vulnerabilities in advance, no matter how 
much testing is performed. Thus, all components must be treated as vulnerable, and systems that 
use these components must be designed with the premise that there may be security 
vulnerabilities in any system component. Even when security functionality is designed into 
commercial products and services, this security is generally weaker than that required for Air 
Force needs. 

This means the Air Force must be able to design—from insecure components and services— 
systems that will be secure against anticipated threats. While the security research community 
has long recognized the need for viable approaches to building secure systems from insecure 
components, very little is known about how to do this, and secure system design remains an ad 
hoc, poorly understood discipline. The notion that it is not possible to discover all vulnerabilities 
and use this information to guide a protection strategy is contrary to current thinking in DoD, 
where the emphasis is on vulnerability discovery, so that appropriate protections can be placed to 
counter these vulnerabilities. This popular “vulnerability discovery” approach puts protections in 
place only where there are known vulnerabilities. But because there is no way that all 
vulnerabilities can be discovered, such an approach will leave the system unprotected from its 
unknown exploitable vulnerabilities, which, if discovered at all, will be discovered only during 
system operation throughout the lifetime of the system. 

This is a dangerous situation, because an adversary may well discover and exploit some of these 
vulnerabilities that are still unknown to the Air Force. In fact, the situation is asymmetric, 
because a determined adversary can decide which part of the system it wants to manipulate or 
exploit, purchase the commercial products used in that part of the system, and spend many 
months deconstructing these products to discover vulnerabilities that can be profitably and 
surreptitiously exploited. While such an approach is clearly affordable by an adversary, it is not 
affordable as a defense, since the defender would have to perform a costly analysis for every 
system component, whereas the adversary can pick and choose its focus of attack. 

This means that red teaming and vulnerability assessments cannot guide a protection strategy (as 
in “penetrate and patch”). A safer strategy is to assume that every system component contains 
unknown security vulnerabilities that can be exploited by an adversary. Where to place 
protections against such unknown vulnerabilities will depend on an analysis of the consequences 
of any of these unknown vulnerabilities’ being exploited. In designing protections, it must also 
be kept in mind that the protections themselves can contain unknown exploitable vulnerabilities, 
so that layers of protection may be appropriate, depending on the estimated consequences of an 
attack. 

4.3.5 Information Management 

The concept of information management (IM) can be developed from Office of Management and 
Budget Circular A-130’s definition of it as the planning, budgeting, manipulation, and control of 
information throughout its life cycle (for example, creation or collection, processing, 
dissemination, use, storage, and disposition). From this relative high-level view, five major 
functions of the information management system (IMS) can be derived. The IMS must 
implement the commander’s policies for access, flow, quality of service, and security 
(information assurance). To implement the access and flow attributes of policy, a transport 
management function needs to span the communication level of the enterprise. Because many of 
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the information sources represent both legacy systems and services provided by other 
organizations, the IMS must provide data (information) transformation functions. The fourth 
function provides basic management of awareness, access, retrieval, delivery, and dissemination 
of information across multiple security environments. The last function is information assurance 
across all functions within the IMS. 

43.5.1 COTS 

COTS technologies exist to implement many of the C IM processes, as the commercial 
requirements are similar to those within DoD. Operating systems such as Solaris and Windows 
NT, messaging languages such as XML, transfer protocols such as Transmission Control 
Protocol/IP, and scripting languages are available and constantly being improved. Data base 
applications and storage applications are widely available as well. Virtually all information 
management hardware (workstations, servers, storage devices) is currently COTS, and there 
seems little reason to change this. Commercial markets that will require the higher levels of 
information management services have not and may not develop. 

43.5.2 GOTS 

GOTS solutions that are being developed are generally tailored versions of COTS solutions. The 
premier example of this is the Defense Information Infrastructure Common Operating 
Environment, which consists of specific versions of COTS operating systems and applications 
grouped together with guaranteed compatibility and a certification process for applications. A 
notable exception to this rule is the DARPA IMS model, which has been partially implemented 
by DISA as the Information Dissemination Management (IDM) program. This IDM service has 
been deployed in European Command, Pacific Command, and Central Command to support 
introduction of the Joint Broadcast Service and the Global Broadcast System. IDM is also a key 
element of the JBI Wright Flyer project at ESC. The IMS is not an alternative to other services 
within the JBI, but provides a meta-service across the entire enterprise. As the JBI leading-edge 
spiral is constructed, the IMS must be the first service implemented to allow other services to be 
integrated as they are deployed. AC2ISRC should develop the concept for IMS and become the 
operational manager for IMS within the JBI leading-edge spiral 

43.53 Deployment 

Deployment of COTS and GOTS IM solutions tend to lag behind the state of the art. For C 2 to 
grow beyond small regional conflicts (Bosnia, Kosovo, etc.) and integrate global sources of 
information (air/space reconnaissance, air/space surveillance, logistics, weather, etc.), the Air 
Force must manage the access, flow, and delivery of information as an enterprise-scale activity. 
IM is an illusive concept. We know it keeps the Internet operating and allows delivery of e-mail 
anywhere in the world with just a name and an Internet service provider, and yet as the Air Force 
considers the development of the JBI, the role of IM is not understood, and there no agreement 
on definition or operational concept. The AC2ISRC should partner with DARPA, DISA, and 
NRO to continue the development of IMS capabilities needed to provide and manage 
information within the JBI. Recommendations on how to speed technology deployment into 
operational applications are included in Section 4.4. 
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4.3.6 Human-Machine Interaction 

This is defined as the elements of the C 2 system that address the bi-directional interface between 
human and machine. Specific concerns of this interaction include handle-ability (ease of use 
plus portal tailoring) of the C 2 interface, synchronized collaborative operation of the hybrid 
(human and machine) decision support system, and a flexible command structure, wherein a 
commander contributes abstract reasoning to a quasi-autonomous decision system and can drill 
down if required or defer if desired. 

To clarify, a decision support system with flexible command structure is intended to harness the 
analytical processing capabilities of autonomous systems to present the commander with a 
rational plan for actuation. If necessary, the execution of planning can become transparent to the 
human being—that is, humans can remove themselves from the C 2 loop after providing an 
abstract objective (the art of command) while the machine determines course of action (the 
science of control). The human can then be re-injected at any point in the C 2 hierarchy if 
desired. For example, human participation may be appropriate in circumstances where time- 
consuming measured reasoning can be accommodated, or even where instinctual-type (assess- 
react) behavior is required, while autonomous decision execution may be used in situations 
where learned (if-then) or analytically optimal decisions provide rapid response. 

Given decision making in a centralized or distributed context, distribution of both status and 
command intent must be considered throughout the hybrid C 2 system. These operations should 
also occur in a manner that allows synchronization of executed events in time, space, and 
purpose. 

Furthermore, to accommodate varying styles of command, the interface from human to machine 
can be portal-tailored to individual preferences. The individualized interfaces should, however, 
be based on a common functionality to avoid disrupting system stability in pursuit of system 
performance. 

4.3.6.1 COTS 

Several technologies are available for leverage in the human-machine interaction element of C 2 . 
Relevant commercial technologies available for near-term application include automated speech 
recognition for transparent interface and 3D audio, separating voices in physical space for 
seamless identification of decision actors. Commercial technologies available for future 
application include untethered C for wireless interface, large-screen seamless projection, and 
flat panel displays (see Chapter 5). 

4.3.6.2 GOTS 

Government technology efforts have seeded a number of cited commercial technologies, but 
GOTS is extremely limited in terms of existing and available technologies for C 2 application. 
More specifically, we believe that Air Force recognition of human-machine interaction as a 
technology area for C 2 investment is essentially absent. Certainly the importance of training is 
recognized. However, there are very important issues well beyond training that are barely 
articulated and for which capabilities are either severely inadequate or completely missing. 
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4.3.6.3 Deployment 

Although COTS technologies are available for translation to government systems, very few have 
been exploited for operational deployment. This inadequacy is manifested in the functioning of 
today’s AOC, which operates in an ad hoc fashion based on a decision cycle with many humans 
in the loop. As with many high-performance systems, the human has here become a limiting 
factor in C 2 due to constrained reaction times. Unfortunately, it is not possible to increase human 
capabilities in the loop by increasing the number of humans involved—the human being is not 
scaleable. In the presence of an increasingly high operations tempo and increasingly high- 
performance mixed-autonomy systems, the decision cycle has become vulnerable to lack of 
coordination and disintegration. To maintain both system stability and performance, future C 2 
must consider the human-machine interaction a priori in terms of interface usability, 
synchronized hybrid operations, and flexible command support. 

4.3.7 Enterprise Systems Engineering 

Enterprise systems engineering is the set of integrated processes and resources that enable 
organizations to effectively, rapidly, and transparently perform their missions across functions 
and, where necessary, across organizational boundaries. There are three aspects of enterprise 
systems: First is the set of automated applications for the end; these support the operations the 
end user or customer wishes to perform. Second is the automated integration of these 
applications into the business processes, transactions, and analyses of the enterprise providing 
products. Third is integrated information sharing across and management of supply network 
resources and organizations. 

A five-layer business model to guide this process is summarized by the following steps: 

• Vision: What the result will be of the effort—how the effort will positively affect the entire 
business mission, under what (emerging) conditions. 

• Business model or value proposition: How the system and practices that it helps implement 
will add value toward achieving the vision. 

• Strategy: What steps, aspects, or priorities guide the development and implementation. 

• Business (operational) process and rules: What re-engineered processes will be embodied in 
and facilitated by the information system, and what rales apply (access to information or services, 
responsibilities, authorities, etc.). 

• Organizational design: What new roles, activities, interactions, organizational forms, and 
practices are required to carry out the vision and business models and to support and evolve the 
new information environment. 

4.3.7.1 COTS 

The best models for the most relevant dynamics and functionality can be found in e-enabled 
business: e-commerce and business-to-business enterprises. We have specific examples in 
industry where systems have been constructed as proprietary systems over private networks, and 
we are beginning to see many examples where these systems are integrated using COTS 
components and open standards for data interoperability communicating over the Internet. The 
COTS components are typically selected and integrated based on an explicit value proposition 
for which the components and the enterprise functionality are then customized. 
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These three aspects of enterprise systems engineering enable the e-business to supply customized 
goods and services to users on an optimized timeline, as well as to optimize processes and 
inventory across the entire supply network (sometimes called a value net). The three key 
technical features that make up the aspects are (1) process re-engineering to optimize throughput, 
responsiveness, and performance of the value net; (2) data and metadata interoperability across 
the network (typically using XML and mapping tools), which may be provided in real time or as 
aggregated data or reports; and (3) automated tools to customize presentation of data and 
customize processes offered to the customer, based on underlying business rules. 

Three things enable the technical side of enterprise systems: reengineered business processes, 
support of these processes with customizable software components, and formal data 
interoperability. Process re-engineering within the retail organization and across the value net is 
performed to optimize throughput, responsiveness, and performance of the value net. Data and 
metadata interoperability across the network (typically using XML and mapping tools to 
translate among data dictionaries) supports data sharing, which may be provided in real time or 
as aggregated data or reports. Finally, automated tools must be developed to customize the 
presentation of data and the processes offered to the customer, based on underlying business 
rules. 

A classic example of enterprise systems engineering with a customer portal web presence can be 
found at Amazon.com. Walmart with its anticipatory and collaborative planning functionality, 
and General Electric with its proprietary back-end value net integration systems, are long¬ 
standing examples of enterprise system engineering in traditional businesses. They have been 
joined by Ford and International Harvester, among others, which are using web-enabled back 
end business integration. 

43.7.2 GOTS 

An enterprise system for C 2 would enable the rapid initial preparation (predictive battlespace 
analysis), strategy, planning and execution, and would support rapid replanning and time-critical 
targeting. Although there are examples of integration of functionality within some DoD 
organizations, and common platforms with shared applications, we could discover no true 
enterprise systems engineering efforts that would provide a basis for development of a C 2 
enterprise system. Although elements of functionality that are useful in the C 2 mission have 
been identified and may soon be available (elements in TBMCS, for instance), there is no true 
componentization of functionality, no interoperable data or metadata standards, and insufficient 
capture and characterization of operational processes. There has been little or no cross- 
organizational enterprise process analysis and engineering, or cross-organizational data 
interoperability development. An enterprise system enables the seamless coordination of 
processes across organizational or functional units to achieve an enterprise goal. 

43.7.3 Deployment 

The approach of choice clearly is to use COTS and build to a set of open commercial standards. 
However, COTS, middleware, and open standards are only a beginning. The most flexible and 
robust approach to creating an open architecture is a layered approach, where a high degree of 
platform independence and component autonomy can be achieved, in contrast to a “Microsoft 
strategy,” which tightly couples functionality from operating system through presentation 
technology. An architecture strategy must be developed to support and unify the spiral 
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development process and to guide implementation choices. Flexibility, expandability, and the 
rapid incorporation of new functionality are best served by a composable component services- 
based architecture using COTS and organizing around commercial component and web 
standards—Java, Hypertext Markup Language (HTML), XML, and standard wrapping 
technologies. One trap that should be avoided is the use of conventional system integrator 
approaches that tie operations and maintenance (O&M) to a custom code base not maintainable 
by multiple vendors. 

A final pitfall to avoid is the practice of regarding legacy systems as the foundation for future 
architectural choices—that is, allowing existing system architectures to dominate the evolution 
of the future system, pointing to the sunk costs as justification. Although legacy system 
functionality need not be discarded, the new architecture should be developed based on 
supporting desired C processes and performance, flexibility, and evolvability criteria, and the 
architectural strategy and plan should focus on adapting legacy functionality into the new plan, 
not vice versa. If an architectural strategy is built around legacy systems and old acquisition and 
software practices, none of the point technologies (HTML, Java, XML) or spiral development 
strategies will achieve the intended effect: A robust, easy to use, evolvable, cost-effective, 
reliable system that is amenable to rapid technology insertion. 

There are many obvious barriers to successfully implementing and deploying an enterprise 
system. Business has typically faced similar challenges. What enabled business organizations to 
move to this collaborative, enterprise-wide, cross-organizational information system was the 
realization that it was of mutual benefit and was necessary to accomplish the commercial 
mission. Collaboration and interoperability were driven by the re-engineering of specific 
processes, not by a mandate to do everything the same way. If we organize our efforts around 
the desired C 2 scenarios and experimentation with new ways of doing business, it will provide an 
operational grounding and definable consequences for eliminating these barriers. 

4.4 Recommendations 

The consensus of the study is that many of the technologies exist which are needed to build the 
JBI and to provide the new capabilities desired to enhance C 2 operations. Many of the barriers to 
moving forward and leveraging this technology base are process or institutional in nature rather 
than technical. Many of our recommendations therefore focus on identifying on how to speed 
technology deployment into the Air Force. In the following sections we describe changes 
recommended to accelerate the technology transition process and better leverage the commercial 
and government research and development (R&D) investment to provide new C 2 capabilities. 

4.4.1 Faster Technology Deployment Through Spiral Development 

The Air Force has elected to move to a spiral development process in support of evolutionary 
acquisition for C 2 systems. 15 This instruction encompasses all system acquisition life-cycle 
activities of C 2 systems, existing or planned, from an initial idea or technological opportunity 
through fielding and sustainment. 

One of the major benefits of a spiral development process over a classic waterfall development 
process is that it does not presume that the requirements are knowable in advance of 


15 Air Force Instruction 63-123, “Evolutionary Acquisition For C 2 Systems. 
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implementation. An example of this paradigm, for new user-interactive systems, is known as the 
IKIWISI syndrome. When asked for their required screen layout for a new decision-support 
system, users will generally say, “I can’t tell you, but I’ll know it when I see it” (IKIWISI). In 
such cases, a concurrent prototyping/requirements/architecture approach is needed, and spiral 
development, rather than waterfall development, processes should be used. 

In January 2000, the Air Force Instruction (AFI) 63-123 required the use of spiral development 
for C systems. It created a hybrid spiral process that fits (uncomfortably) into the DoD 5001 
and 5002 series of regulations. Despite the fact that this instruction is too new for any program 
to have executed under it, it is clear that while the use of spiral development is the correct 
approach, our understanding and direction today need some refinement. 

We need to stimulate industry development of a standard for spiral development. The 
February 2000 Joint Symposium on Spiral Development called for such a standard, and 
Government participation would accelerate the process. By moving from standardization (a 
process owned and mandated by the Air Force) to mandatory compliance with a flexible standard 
the Air Force can reap many benefits. Once industry has created this standard, AFI 63-123 can 
be greatly simplified, and discuss only how to fit spiral development into the acquisition process. 

The role of cost as an independent variable (CAIV) in spiral development must be emphasized. 
Funding timelines make dynamic reallocation difficult. In this environment each spiral increment 
is unlikely to receive funding directly commensurate with the desired accomplishments of that 
increment. After determining the desired level of risk reduction and functional addition ideal for 
a phase, CAIV processes are essential to determining how much of each should actually be done. 
Learning how best to apply CAIV processes to spiral development is an essential task that should 
be done by a Government-industry team. 

We must define critical interfaces and elements of the user interface with considerable rigor in 
advance. These are the portions that affect other developments and the entire training process. 

We must allow these elements to evolve slowly and with a great deal of thought to the impacts to 
users and other systems and allow all other aspects of the architecture to evolve freely from 
spiral to spiral. 

4.4.2 Move to Procurement Through Concept of Operations (CONOPS) 

The Air Force is slow to incorporate new information technologies into C systems. One of the 
reasons for the delay is that procurement of information technology (IT) systems proceeds 
through the same requirements process as for purchasing an airplane or a ground vehicle. The 
idea of developing commercial systems by satisfying detailed requirements was discarded long 
ago by the business community. Rapid development of new applications by commercial industry 
is done on the basis of a stated operational need and through close collaboration between 
developer and user. 

The Air Force analog to procurement from need is procurement through CONOPS. Usually, 
suggestions for new capabilities result in a CONOPS. It should be possible to procure a system 
to provide needed capabilities by simply replacing multipage requirements documents with a 
CONOPS document. The reduction of needs to requirements is a process that frequently results 


16 Air Force Instruction 63-123, Evolutionary Acquisition for C 2 Systems. 
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in errors than are reflected in the final product. After all, what is truly required is a capability, 
not the satisfaction of a formal process. 

It will be necessary to establish an evaluation group to certify that the operational capabilities 
have, indeed, been established. The group should be populated mostly by users of the new 
system but should include technologists and system developers. The group must be a hands-on 
user group. The integrated product team (IPT) model is not acceptable. The IPT process has 
become so bureaucratic that it is hardly useful in the modern world of military procurement. 
Membership is frequently at the wrong management level. For the CONOPS procurement 
method to work, the evaluation group must consist of people at the working level—that is, users 
and software and computer developers. Such a radical change in process may not be popular 
with contractors, but the purpose of the Air Force acquisition process is to provide new 
capabilities, not to procure new “widgets.” 

A CONOPS can be a simple overview of connectivity and functional nodes, or it can be a set of 
detailed descriptions of connections, information flows, activities, interdependencies, and 
timelines for a number of possible scenarios or conditions from the perspective of different user 
organizations. These descriptions can be represented in simulations that provide performance 
and flow dynamics over time. The latter version of CONOPS is the approach currently taken by 
AC2ISRC, and the approach that will yield data appropriate for acquisition in the spiral 
development model. These CONOPS provide a rich model for developers and contractors to 
determine performance needs, and it opens up the technical trade space and technology options 
to provide the capabilities needed in a timely, cost-effective fashion. The functional node 
representation along with the dynamic simulation allows the detection of successive gaps and 
bottlenecks in the process and identifies high leverage points for technology development and 
insertion. This approach ensures optimal, operationally significant improvement in defined 
processes and is far more reliable in ensuring operational capabilities than the formal 
requirements process. 

4.4.3 Planned Divestiture for Obsolete Systems 

Sustainment is a big bill to pay and a significant barrier to technology transition. During the 
2002 Program Objective Memorandum, the MAJCOMs identified 240 sustainment disconnects 
and initiatives of nearly $3.5 billion unfunded annual. U.S. Air Forces in Europe and the Pacific 
Air Forces requested a 50 percent increase in O&M across the Five-Year Defense Plan. Increase 
in capability, historically, is not programmed with proportional increase in support infrastructure. 
Much of this bill is the essential infrastructure and training needed to underpin our C 2 ISR 
capabilities. Facing these huge bills, the MAJCOMs are often unwilling to add new capabilities, 
which only adds to their sustainment burden. Hence, many outstanding technologies, and the 
military capabilities that they enable, remain in the labs and in the industries where they were 
developed. 

In today’s budgetary environment, the only way to afford new capability is to divest of old 
capability. Given that the Air Force cannot pay for everything it wants, difficult decisions need 
to be made as to which capabilities are truly needed and which are not. Something good 
generally must be given up to pay for fielding something better. These decisions are very tough 
to make and require involvement of the most senior leadership in the Air Force and DoD. The 
Air Force needs to consider the current investment in C and ISR—is it sufficient to carry us into 
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the warfare of the Information Age? This assessment should focus on overall capability, not on 
individual programs. A process needs to be developed in the Air Force for identifying legacy 
systems that are beyond their effective lifespan. 

4.4.4 Timely Application of COTS 

In the C 2 information technology environment, the deployed capability is usually 3 to 7 years 
behind the state-of-the-art technology in the commercial world. The commercial IT engine tends 
to turn over technology in 8- to 15-month cycles due to upgrades in software/hardware and 
changes to respond to market forces. The result to the military is that much of the COTS 
technology being deployed in C 2 systems is already outdated by the time it is delivered to the 
operational warfighter. There are multiple reasons why this problem exists: 

• First, many IT acquisitions have used a waterfall development cycle that freezes the COTS early 
in the development cycle with no plan to upgrade as new releases are announced. The acquisition 
process has allowed contractors to modify COTS to better fit operational requirements, with the 
result that the capability is no longer COTS and costly upgrades are needed to add new 
capabilities that otherwise would have been available in the next-generation COTS product. 

• There are no general plans to accommodate new releases and upgrades during development, as 
funds set aside to do this have proved difficult to defend. 

• The COTS developer is usually forced to work through a prime integration contractor. The result 
of this is that the COTS developer is often not integrally involved in plans for future 
development, and the integration contractor is not always aware of what next-generation COTS 
products will be able to accomplish. 

To avoid these problems in the future, the Air Force should plan to build C 2 systems, where 
possible, using unmodified COTS products. Enterprise licenses should be negotiated for core 
COTS products to facilitate their ubiquitous use operationally. Using the built-in development 
tools available in the current generation of IT products, many operational needs can be satisfied 
by distributing freeware—customized scripted programs that run on COTS applications. 

4.4.5 Facilitate Science and Technology (S&T) Transition 

The task of transitioning technology developed in AFRL and Battlelabs has been a primary area 
of concern and a constant source of frustration. While technology development always involves 
the failure of some efforts due to technological limitations, the process of incorporating into Air 
Force C systems those pieces that do succeed has, for the most part, also failed. The sources of 
this failure range from poor communication to long, bureaucratic processes that result in 
technology obsolescence before new capabilities can even be deployed. While much of the Air 
Force’s C 2 needs can be addressed by leveraging commercial technology, there are areas where 
focused investment is needed to develop capabilities where no commercial market analog exists 
(see Figure 4-1). It is essential that the Air Force and DoD’s investments in these areas can 
rapidly transition into operational use to augment the capabilities available from COTS 
information systems. 

The primary barrier to technology transition from the laboratories in the IT fields was perceived 
as being due to a lack of communication between technology developers and the actual users. 
This communication is essential early on in the development process to connect the technology 
push to the operational user pull. With the current Air Force R&D process, the communication 
to the laboratory of the C capability needs and requirements is through multivolume documents 
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published by the AC2ISRC. This process is a poor substitution for establishing communication 
between the technologist and the operator during development. Without this connection, the 
technology developers are frustrated by not knowing what the users want, and the users are 
frustrated that the technologists cannot meet their needs. Moreover, the time spent by the 
technologists to track down what was meant by a specific capability need and how complex the 
need truly is detracts from the productive time spent on the development effort. 

The consolidation of C requirements by AC2ISRC is useful endeavor that can result in one-stop 
shopping to match a technology with a need. But often the result is the direct isolation of 
technologists from users and their environment, causing confusion, and a lack of user context. 
There needs to be a better teaming approach among the Air Force laboratories, Battlelabs, 
AC2ISRC, and the user community to better facilitate overall communication. Improving this 
communication can lead to more effective transitions of technology. 

Where a good teaming relationship has existed between the laboratory and the user community, 
technology transition has proved to be very successful. Without this relationship, the technology 
transition record through the acquisition program has proved abysmal. For example, the 
Intelligence Division at AFRL/IF has been very successful over the past three decades by 
working very closely with the intelligence users to develop the requirements together and 
explore the space of what is possible and by developing these systems for direct insertion to the 
field. The current Broadsword effort at AFRL/IF is an example of spiral development where a 
small team of developers and users consistently worked together to produce a technology 
product that is fielded, meets users’ capability needs, and is constantly improved with user 
involvement. Another example of a transition success has been the technical relationship 
established between AFRL/IF and AMC. While embarking on Mobility 2000, a major initiative 
to improve its C 2 and business practices, AMC understood that technology could not solve, but 
could help improve, those processes to better match the much more efficient processes found in 
the commercial airline industry. AMC and AFRL/IF signed a Memorandum of Agreement that 
established an “information technology pipeline” between IF and AMC. IF would constantly 
look at its tech base, consisting of GOTS development via DARPA and COTS tools to look for 
new solutions to the capability needs of the initiative. This resulted in the establishment of an 
AMC/IF Skunk Works concept and facility, where new, innovative solutions could be tried in a 
realistic environment. This type of “honest broker” relationship has resulted in several ongoing 
transitions of information technology to operational AMC systems, with spirals taking place both 
during and out of cycle with JEFX. 

The majority of information technology funds managed by AFRL/IF are provided by DARPA as, 
over the years, the Air Force’s S&T investment in this area has shrunk drastically. AFRL/IF has 
taken a portion of the dwindling Air Force S&T 6.3a funds to attempt to facilitate the transition 
process. This facilitation occurs by forming critical experiments and Technology Integration 
Experiments (TIEs), which involve an Air Force user and a specific Air Force user need. 

Because these are experiments, some of these TIEs fail or are dead-end engineering, while others 
are used as an initial technology transition spiral. The result so far is that several have 
transitioned to users, while others promote subsequent TIEs, therefore becoming subsequent 
spirals, and others have developed into entirely new technology programs. 
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4.4.6 Leverage New Sources of Technology for the Air Force 

The Air Force’s future will require the ability to rapidly respond to a changing and uncertain 
future mission. The current large-scale vertically integrated monolithic integration process is 
based on a single prime contractor and a rigid requirement process. The Air Force’s ability to 
obtain access to innovation and emerging technologies that ensure a competitive advantage are 
severely restricted by this rigid acquisition model. Industry has evolved to a horizontally 
integrated, segmented acquisition model based on the following three principles: (1) a simple 
underlying architectural model based on standards, (2) an acquisition strategy based on 
component development that heavily leverages software reuse and existing product services due 
to the premium for access to talent and pressure to reduce time to market requires an acquisition 
strategy, (3) a business model that encourages and rewards competition, sometimes competing 
for the same market (in the case of the Air Force, the same mission need). These principles are 
now transforming the global economy. 

The transformation occurring in the global economy from a highly structured sequential 
investment strategy to the very flexible, dynamic, rapid time-to-market new economy model 
places great emphasis on rapid product insertion into the marketplace. This new economy model 
places importance on information-based business processes and how these processes guide 
investment and innovation. The Air Force can exploit a parallel strategy using the spiral 
development process to guide the rapid development of new technical capabilities into the 
operational environment by following management processes similar to the new economy model. 

As the Air Force moves toward the new economy model in spiral development, it will need to 
focus on how resources are invested by leveraging the most innovative components of industry, 
DARPA, university consortia, the Air Force, allies, and joint-Service laboratories and Battlelabs. 
Also, one of the most overlooked sources of technology innovation is the Air Force’s own 
workforce. Modem information products are becoming more sophisticated and allow 
operator/users to “program” these applications using customized scripts to perform complicated, 
special-purpose information management tasks. With the pressures being placed on industry to 
produce better products more rapidly and with fewer engineering personnel, this trend can be 
expected to continue. This predicted transition is analogous to the change in the telephone 
system where technology had to be introduced to replace operator-connected calls with 
automatic dialing. Without this technology change, the prediction was that every person in the 
United States would need to become a telephone operator for the telephone system to run. 
Without the technology to provide user-friendly customization of complex software applications, 
a similar prediction would be that every person in the United States would need to become a 
software programmer for the e-commerce revolution to continue. 
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Figure 4-2. New Sources of Technology 


The current acquisition process is geared toward large-scale procurements through a prime 
integration contractor familiar with the Air Force’s legacy C 2 ISR systems. While, for large scale 
systems, this approach has proved necessary, the Air Force needs to reach out to alternative 
technology sources to achieve the benefits of the flexible, dynamic, rapid-time-to-market new 
economy model in the next generation of C 2 ISR systems. The technology sources we suggest to 
be better leveraged are shown in Figure 4-2. 

4.4.6.1 Small Business Technology Sources 

Much of the information revolution is being fueled by small businesses and e-commerce new 
starts. These are not ordinary defense contractors. The Air Force can outreach to these small 
innovative industries through better use of the Small Business Innovative Research (SBIR) 
program. Congress provided this means to gain access to these small industries with funding 
already set aside within the Air Force budget (6.5) for R&D. The SBIR program is conducted in 
three phases. The first phase provides an initial assessment of the technology, the second phase 
concludes with a limited demonstration of technology feasibility and maturity, and the third 
phase transitions technology into co mm ercial use or into Federally funded R&D. 

In creating the SBIR program, Congress created a means for the Air Force to focus an 
investment in innovative technology by providing resources independent of research, 
development, and acquisition program funding. Congress’s approach was to give an incentive 
for small business’ access to Government funding by setting aside two and a half percent of 
development funding to the SBIR program. In C 2 , these SBIR set-aside funds are a significant 
R&D investment in comparison with the AFRL/IF discretionary Exploratory and Advanced 
Development funding, which has been declining in the area of IT. 

The current management process for C 2 SBIR does not follow a central strategy coordinated with 
the AC2ISRC vision. The SBIR topics are nominated by AFRL and the acquisition program 
offices (Program Executive Offices) and the Designated Acquisition Commanders. This chaotic 
approach leads to few technology transitions from the SBIR investment into operational 
capabilities. Increased focus and technology transition would result from investing the C 2 
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component of the SBIR funds (those C programs taxed) based on a central strategy developed 
and managed by the AC2ISRC. The execution of these SBIR funds should be managed by 
AFRL. This strategy could be used, for example, to give small business an incentive to develop 
and demonstrate technologies for the JBI. 

If the AC2ISRC were to develop and operate a leading-edge experimental testbed (for example, 
CAOC-X), a large number of innovative concepts (arising from large aerospace industry, Service 
laboratories, and SBIR) could be evaluated. Those demonstrating utility to AC2ISRC and that 
were sufficiently mature would rapidly move to an operational prototype for testing and 
evaluation by the users. A budget should be set aside for Phase III transitions to rapidly occur 
from successful SBIR development efforts. 

4.4.6.2 DARPA as a Technology Development Partner 

DARPA is making a significantly larger investment in IT than the Air Force is. This could be 
better leveraged within the Air Force by re-establishing the long-standing relationship that the 
Air Force had previously with DARPA. Up until the past 10 years, the Air Force agenda 
dominated the investment strategy at DARPA. The Air Force not only provided 90 percent of 
the military workforce but also sent only its most competent and trusted officers to DARPA. 
Because DARPA possesses both a culture of innovation and a budget to support inn ovative 
solutions the rebuilding of this close relationship will be critical for the JBI. 

The Air Force Technology Executive Officer should assign adequate quality personnel to 
DARPA to ensure that the Air Force’s JBI objectives are met. DARPA is not currently part of 
the JBI process and yet the SAB 1998 Summer Study proposing the JBI was founded mostly on 
DARPA technologies. The AC2ISRC should lead an effort to define future operational concepts 
and technology needs for DARPA to focus the development of needed technologies. The 
AC2ISRC should additionally ensure that DARPA is integrated into the leading-edge spiral JBI 
experimental evaluation process. 

4.4.6.3 University Research 

Many of the emerging information technologies needed for the JBI begin in the university 
system. Air Force Office of Scientific Research (AFOSR) and AFRL have an ongoing research 
relationship with specific components of the university system for more generic technology 
development. Working with concepts developed by the AC2ISRC, AFOSR, and AFRL should 
encourage investments in university research that lead to new capabilities for the JBI. AC2ISRC 
should provide access to the leading-edge spiral JBI environment for experimentation and 
evaluation of these emerging capabilities. 

4.4.6.4 Joint-Service and Allies ’ Laboratories 

A major source of new technology and concepts for interoperability is other Service labs and our 
allies’ laboratories. One major challenge facing the JBI is the integration of other Services and 
our allies into C 2 operations. The leading-edge spiral JBI provides both the platform for other 
Service technology demonstration, and it exploits the technology and policy issues of combined 
C 2 operations. AC2ISRC should develop processes and procedures to guide the development of 
technology that enables combined C 2 operations within the leading-edge spiral JBI. The JBI 
testbed should be expanded to allow joint-Service laboratories and our allies to participate in 
development of the JBI. 
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4.4.6.5 Air Force Operators as Technology Developers 

Perhaps the most important source of innovation for next-generation C 2 ISR systems is the “blue 
suit” officers and enlisted personnel in the Air Force. These people are experienced in the Air 
Force’s mission and technology needs and represent one of the most valuable sources of mission- 
specific solutions. Because of frustration with the current acquisition process, many users are 
developing workarounds or patches using COTS tools to improve their daily productivity. Many 
of these “temporary” fixes have subsequently proved to perform better than their core system 
counterparts once they have been fielded. This occurred because of the following two essential 
ingredients: (1) in many cases, the operators themselves best understood the existing C 2 process 
they were following and how to improve it; (2) the COTS information tools used to develop the 
improved process included sophisticated customization capabilities allowing an essentially new 
software to be developed using scripts rather than raw software. Since this trend can be expected 
to continue, the Air Force should establish a process whereby these operator-developed systems 
can be adopted into the core C 2 ISR systems. This will require the development of standards for 
documenting and sustaining these new applications. Since these have been developed using 
commonly used COTS products, by operators, for use by operators, the sustainment cost will 
likely be significantly lower than for custom-developed applications. For example, training to 
use a new application for an operator already familiar with the core software product and with 
the C process being followed would likely be no harder than learning to use a new Web 
browser. 

The Air Force, like other governmental organizations, faces the loss of quality people with 
information skills to opportunities outside government. The Air Force should consider creating 
an adjunct to AC2ISRC that gives hand-selected individuals opportunities to develop, evaluate 
and deploy rapid advances in the technologies needed for the JBI. The Air Force should 
implement a career rewards program for the most successful individuals to ensure that they 
continue their Air Force careers. 
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Appendix 4A 
Technology Panel Charter 

1. Identify the technologies that can enhance present and future C systems with a near-term 
emphasis on the following capabilities: 

• Network-centric operations 

• Interoperability within the Air Force, with the other Services, and between legacy stovepiped 
systems 

• Timely and effective communication 

2. Provide support to the Concept and System Definition and Interoperability panels on 
technologies that are: 

• Available for the 2005 system 

• In development and which might bridge to providing JBI capabilities 

• Needed before the JBI can be implemented 

3. Provide recommendations to the Concept and System Definition and Interoperability panels 
on technologies that could be available to field in near-term operational demonstrations (for 
example, Expeditionary Force Experiment 2002). 

4. Work with the Acquisition Panel to investigate methods for speeding transition of technology 
from development, experimentation, and operational demonstrations to fielded implementation. 

5. Investigate COTS technologies that can be leveraged with an emphasis on near-term 
capabilities that could be fielded to evolve the JBI. 

6. Technology areas to be investigated will include (but are not limited to) 

• System and software development processes and tools 

• Planning and decision making aids, models, and tools 

• Communications 

• Data links and message protocols 

• Network architectures 

• Multi-level security 

• Data fusion, management, and presentation 

• Geolocation and targeting 
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Appendix 4B 

Technology Panel Membership 


Dr. Alison K. Brown, Chair 
President 

NAVSYS Corporation 

Dr. Thomas A. Brackey, Deputy Chair 
Executive Director, Technical Operations 
Hughes Space and Communications Company 

Dr. Duane A. Adams 
Vice Provost for Research 
Carnegie Mellon University 

Mr. Timothy M. Bonds 
Analyst 

The RAND Corporation 

Mr. John N. Entzminger 
Private Consultant 

Dr. Gene H. McCall 
Chief Scientist 
AFSPC 

Prof. Alan S. Willsky 

Department of Electrical Engineering and Computer Science 
Massachusetts Institute of Technology 

Maj Kenneth S. Kreit 

Program Manager, Large Aperture Spacecraft 
National Reconnaissance Office 

Advisors: Dr. Kevin B. Kreitman, Aerospace Corporation 

Mr. Richard Metzger, AFRL/IF 
Mr. Jay Scarano, MITRE Corporation 
Maj Michael J. Estes, C 2 ISR Center 
Maj William Richard, SAF/AQII 

Executive Officer: Maj Timothy P. Nickerson, AMC/XPX 
Technical Writer: Maj Joseph E. Brouillard, USAFA/IG 
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Appendix 4C 

Defense Information Infrastructure Common Operating Environment 

(DII COE) 


1.1 Introduction 

The Air Force is becoming increasingly dependent on using commercial software in major 
defense systems. Examples include the Airborne Warning and Control System and the Theater 
Battle Management Core System (TBMCS). The major benefit of using commercial-off-the- 
shelf (COTS) software is that the Air Force can leverage the huge investment being made by the 
private sector to develop software that is very similar if not identical to that needed by the Air 
Force. Furthermore, exploiting commercial software lets the Air Force stay at the leading edge 
of what is available. The days when the Air Force led the commercial sector in developing 
software-intensive systems are gone and not likely to return. 

There are a series of obstacles which must be overcome in order to take advantage of COTS 
software. The biggest obstacle to successful commercial technology incorporation is inflexible 
requirements. Effective use of COTS products demands flexible requirements from the outset 
and a trade-off process that extends throughout the entire engineering, manufacturing, design, 
testing and fielding process. A second obstacle is that commercial computing and 
communication technology is a “moving target” that must be dealt with continuously throughout 
the life-cycle of the system. A major system, composed of many products developed by a 
number of different vendors, can be very difficult to maintain by the traditional method of 
periodic releases, say every 18 months. This is because the commercial products are on 
independent development cycles, many much shorter than the periodic release cycle. The 
periodic releases may introduce new functionality as well as fix bugs. A fixed 18 month release 
cycle means than much of the software in the system is obsolete for the bulk of the time it is in 
production. This can result in frustration for the users who want to take advantage of newer 
technology, and can be a burden for developers who must continue to build on an old technology 
base. This must be balanced against the risk of introducing upgrades and new products, that may 
introduce software errors or perturbations in the testing environment. 

Commercial technology that we wish to exploit comes in many forms, including system 
software, applications software, appliance devices such as personal digital assistants, and 
development tools such as scripting languages. Complementing the commercial products are 
research products from organizations such as the Defense Advanced Research Projects Agency 
(DARPA), Air Force Research Laboratory (AFRL), ACTDs, Battle Labs and locally-developed 
software products which meet the needs of particular user communities. The challenge is to find 
a process that encourages and facilitates the use of this expanded technology base while 
preserving the integrity of the systems that must remain operational during the transition. 

This document discusses one particular part of the infrastructure, the Defense Information 
Infrastructure Common Operating Environment, better known as the DII COE. 
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1.2 What is DII COE? 


At the highest level of description, the DII COE is a creation of the Department of Defense 
(DoD) designed to: 

• Facilitate joint system interoperability 

• Improve functionality for the warfighter 

• Realize savings in system life-cycle costs 

At another level DII COE is: 

• A reference implementation of the DoD Joint Technical Architecture (JTA) 

• A software infrastructure 

• An approach to facilitate integration 

• An approach to improve software engineering discipline 

In terms of components, DII COE is composed of: 

• Operating system services (Unix, NT) and windowing (X, Motif, NT) 

• Infrastructure services (printing, Web servers, communications, management services, toolkits, 
etc.) 

• Database schemas and metadata standards 

• Common support applications (office automation, message processing, etc.) 

• Standard applications programming interfaces 

Applications run on top of DII COE. TBMCS is such an application. 

1.3 Why have a Common Operating Environment (COE)? 

You might wonder if the DoD is the only entity that has a COE, and it clearly is not. Most major 
corporations have a COE and a software development process for their internal use. The main 
reason for having a COE (and the tools that support it) is to facilitate the installation, operation 
and maintenance of applications. The DoD COE goes a step further than most organizations, 
prescribing rules to ensure that applications do not interfere with each other when concurrently 
installed on the same piece of hardware, and supplying installation software that provides 
capability beyond commercial technology. 

Vendors of major computing systems often provide a similar environment and support tools. For 
example, most PC users are familiar with a Microsoft operating system (Windows 95, 98, or NT) 
and many of the applications that one might choose to install (for example, Norton anti virus 
software or the Netscape browser) come with the tools necessary to install them on a Microsoft 
platform. The same is true for applications on an Apple, IBM, Dell, or Sun platform. However, 
the environments provided by Microsoft, Apple, and Sun are different. So are their tools, and 
one cannot depend on all third party software systems (for example, Norton anti virus software) 
to follow any particular convention for installing and de-installing their applications. Nor can 
one assume that the installation of a new application or a product upgrade won’t break some 
other application. It is a user-beware environment today. 
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The DII COE is built primarily using commercially available software systems. The current 
version is typically referred to as the COE 4.x series. COE 4.x includes Solaris 7 and 8, Oracle 
8i, Windows 2000, and many other features, including more extensive use of Java. COE 5.x will 
include updates to the standard platforms mentioned above and real-time support such as the 
Lynx Operating System and real-time CORBA products. Current TBMCS, because it has been 
in development for several years, will be fielded on COE 3.1 for the Navy and COE 3.3 for the 
Air Force. COE 3.x includes Sun’s Solaris 2.5.1, Oracle’s 7.3.2.3 database and Microsoft’s 
NT4, among others. COE 3.x will be in the field for several years to support TBMCS 
operations. 

One of the key concepts in the DII COE is the Integration and Run Time Specification (I&RTS). 
This specifies the run time environment and informs application developers of their 
responsibilities if they are building applications to run on the COE. The focus is on allowing run¬ 
time integration. There is an 8 level hierarchy that describes various levels of compliance. 

Level 5 compliance is the near-term goal for most applications. It is commonly described as 
“peaceful coexistence”, meaning that when an application is loaded on a platform or un-installed, 
it will not adversely affect any other application on the same platform. 

The above description is only meant to indicate the general direction of the DII COE evolution, 
not a complete description by any means. This is clearly a significant undertaking for the DoD. 
Counting the COTS and government-off-the-shelf (GOTS) software in DII COE, there are 
reportedly over 1 billion lines of code. While most of this code is in the form of major 
commercial components (Solaris, NT, Oracle, etc.), it also represents a significant amount of 
GOTS software (20 million lines for the Common Operational Picture [COP] alone) and there is 
replicated functionality with what commercial organizations would normally supply with their 
products (for example, the kernel includes a common desktop and software installation tools). It 
is Defense Information Systems Agency’s (DISA’s) stated intention to get out of the kernel 
business and rely on commercial products as much as practical. We believe this is a good move. 
However, achieving and maintaining parity among the various computing platforms will remain 
a challenge. 

1.4 TBMCS and DII COE 

TBMCS is a major application that uses DII COE. TBMCS was one of the first to use the COE, 
and as such experienced many of the DII COE’s growing pains. This points out the problem of 
implementing policy before the execution plan and technology are ready. It has been estimated 
that having to comply with DII COE cost the TBMCS program about $9 million. We are not 
able to establish that this cost is due to DII COE alone, or whether some of the costs are related 
to other factors. These could include having to segment legacy applications, modifying 
applications to integrate upgrades for commercial products that are part of the COE, and 
imposing good software engineering practices. 

TBMCS will be used by both the Air Force and the Navy, and today these Services operate on 
different hardware bases (the Air Force on Sun hardware and the Navy on HP hardware). There 
is a portability issue, but at this time we do not know the extent of this as a problem. 

DII COE is on an 18-24 month cycle for introducing major releases. The release cycle is 
managed by an Architecture Oversight Group and a Configuration Review and Control Board 
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that takes into account the development and fielding schedules of the major command and 
control (C 2 ) systems. The commercial products that will be used to implement the kernel, 
infrastructure services and common support applications are identified, baselined, and published. 
Programs then decide if they will use the new release as a foundation for their system 
development, or if they will retain an older version of DII COE for existing systems such as 
TBMCS. Once development has started, the program office must consciously decide whether to 
accept any changes to the baseline. 

Establishing a new baseline is just the beginning. TBMCS must then be integrated in the new 
system, tested, validated and released to the field. It is likely that some of the commercial 
components will be 2 to 3 years old before the user ever sees the software. During that time 
there may have been one or more releases of the commercial software. This issue needs to be 
addressed—independent of DII COE. 

There has been concern about the time lag between the introduction of commercial software and 
the inclusion as a COE component. For upgrades to software already in the COE, there is a 
relatively short process, typically measured in weeks. For new products, there can be a very 
lengthy process that can take months or even years. It is possible to treat a product that should 
eventually be integrated into the COE as a mission application, thus simplifying the compliance 
process. This concept is described later in the document. 

Even when new software shows up in the COE, it may not be used by the TBMCS development 
community. Risk analysis is done to determine if the benefits of introducing a change to the 
baseline is warranted. The further along in the development and test cycle, the lower the 
probability that any given upgrade will be accepted, further reducing flexibility and causing the 
Air Force to fall even further behind the COTS world. 

1.5 An Assessment of DII COE 
1.5.1 Standards vs. Standardization 

Standards are most effective when they formalize a set of rules or protocols that make sense and 
are necessary to perform a given function. In the case of the Internet, the Transmission Control 
Protocol/Intemet Protocol protocols allow communication between computers that are made by 
different manufacturers, run different operating systems and may even be on different networks. 
These standards are simple and in widespread use. Other standards related to this study include 
Extensible Markup Language (XML), hypertext markup language, CORBA, etc. 

Standardization, on the other hand, is a process that may mandate detailed compliance with a set 
of processes or rules. It some cases the use of standards alone is inadequate, and standardization 
is necessary. The developer of a computer system may want to ensure that subsystem developers 
comply with a common look and feel, follow standard documentation processes and use a 
common set of development and installation tools. Standardization often imposes a greater 
burden (in both time and cost) on those who must follow the standardization processes. The 
benefits of standardization must be examined in terms of their system costs. 

The current DII COE process is viewed as requiring excessive standardization. Use of DII COE 
is mandated for all command and control, intelligence, surveillance, and reconnaissance systems. 
Those wishing to deviate from the process must request a waiver. For DII COE component 
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vendors, not only must the developer adhere to the design standards (segmentation, etc.), but 
there is a complex design review and compliance testing process that involves final approval 
from DISA. To mitigate the schedule risk associated with introducing a component into the 
COE, users are encouraged to initially segment and use the software as a Mission Application. 
This allows the users access to the application while the acquisition community executes the 
process of turning the software into a component. The distinction between COE components and 
Mission Applications is significant to developers, and is briefly described below. 

Both Mission Applications and COE components require that the software be segmented and 
compliance tested. Segmentation is the engineering activity that makes the software available 
for integration. The I&RTS rules must be followed to ensure that the software will behave 
properly when installed on an end-user platform. Compliance testing verifies that the software 
has been segmented correctly—that it installs, de-installs, and can be started from the desktop. 
For a mission application, this is all that is required for DII COE compliance. 

Software that will become a DII COE component has additional requirements that must be met. 

A formal requirements analysis and design review must be performed on the software. The 
formal requirements analysis results in the generation of a requirements traceability matrix. This 
allows developers to determine, at a gross level, which product will best meet their needs from a 
technical perspective—particularly important if there are multiple products available in a given 
solution space. Performance requirements are not addressed, so the developer must determine if 
the product will be acceptable for their application. For technology where mature standards exist 
and technical requirements are well defined, this process does not take long, on the order of 2-3 
months. Difficulties arise and timelines are longer when attempting to componentize products 
related to new or immature technology. In this case, there may not be relevant standards, and 
technical requirements may not exist. Then, the technical requirements must be developed 
before the requirements analysis can be done. This can be an arduous task taking months or 
years to resolve. 

1.5.2 Interoperability 

One of the goals of the DII COE is to support interoperability. At level 5 compliance with the 
I&RTS, this means “peaceful coexistence”; that is, applications do not interfere with each other. 
What we really want is “semantic interoperability”. This means that there is a shared 
understanding of the meaning of a concept of data element, and hence every application will 
correctly interpret the data it obtains from every other application. Past efforts to establish 
semantic interoperability have attempted to create standard data dictionaries and to mandate 
compliance with a common registry of terms and data elements. This approach can be made to 
work for a small community over a small subject area, but it is not feasible for semantic 
interoperability across the entire DoD. The difficulty of this approach is illustrated by DISA’s 
success (or lack thereof) in defining common data elements for Global Command and Control 
System. To date they have achieved only partial agreement on 5 entities (representing on the 
order of 100 standard data elements); they reported that they have over 11,000 elements to go! 

The introduction of the XML has been an important first step toward achieving interoperability 
at the syntactic level. Current research aims to build on the XML concepts and to extend the 
language to achieve semantic interoperability. If this research achieves its goals, there will be a 
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major opportunity to achieve semantic interoperability without imposing a requirement on users 
to have complete agreement on standard data elements. 

One of the new technologies being developed to support semantic interoperability between 
systems is the DARPA Agent Markup Language (DAML). The goal of DAML, based on XML, 
is to provide not just machine readable, but machine understandable content for other DAML 
enabled software agents, programs and systems. DAML will be a semantic language that ties the 
information on a page to a machine-readable semantics (ontology). Language compliance will 
allow for military and commercial information technology communities to develop ontologies 
for their own use while also allowing the sharing of these ontologies between organizations. To 
address the adoption of DAML, DARPA is working with the World Wide Web Consortium 
(W3C) to insure that such technology fits within future W3C recommendations for the semantic 
web. 

Another new technology that promotes rapid heterogeneous systems interoperability is the Agent 
Grid from DARPA’s Control of Agent Based Systems (CoABS) program. The Agent Grid 
constitutes a service-based middleware which provides shared access to protocols, services, and 
ontologies to agents, object, and systems. The Agent Grid is built using Sun Microsystem’s Jini 
and Java Remote Method Invocation which provides the ability for agents and systems to 
describe the services and information they can provide and how to use them. The grid then acts 
as the glue between these systems and communities of agents. 

The Scientific Advisory Board believes that the combination of the CoABS grid and DAML 
described above will be a critical enabler for the Joint Battlespace InfoSphere (JBI), and 
recommends that the AFRL work closely with DARPA to make sure that these technologies are 
introduced to industry and transitioned into the JBI program at the earliest possible time. 

1.5.3 Security 

Most security requirements within the DII COE kernel are implemented using native OS 
capabilities. When properly configured, native OS security capabilities meet many DII COE 
user requirements, and there is the option of developing capabilities to meet requirements that 
are not satisfied by the OS. DII COE system integrators can also use COTS security solutions as 
mission applications, or as COE components, depending on the product, its market share, and its 
status with respect to the COE process. DISA has also been working with OS vendors to 
improve the security of their products and has implemented a process for assessing the impact of 
vulnerabilities identified by the Information Assurance community on DII COE products. OS 
patches are identified or developed and incorporated into the kernel to fix security problems as 
appropriate. 

Security of the kernel has improved over the past several years by incorporating a fundamental 
change in kernel delivery. In the past, system integrators were responsible for configuring the 
kernel to meet their security needs. Now, the kernel is delivered pre-configured in a locked 
down state. Systems integrators work with Program Managers and the Designated Approval 
Authority to balance security risks and software integration needs. Also, the kernel undergoes 
considerably more security test and evaluation than in the past. Each release of the kernel 
undergoes a Kernel Security Assessment, the results of which are fed back into the development 
process, and vendors if necessary. 
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Finally, security is a part of the DII COE compliance and software acceptance process. There is 
a new security chapter in the I&RTS, adding to and/or strengthening each COE compliance 
level. 

The process outlined above is reasonable. The real security vulnerabilities are not likely to be in 
the individual components of the DII COE but in the “seams” as one integrates components from 
multiple vendors, whether in the COE itself or as mission applications. This is an area where an 
overall security architecture is badly needed, where there must be particular attention to security 
in system testing, and where new technologies must constantly be examined for possible use in 
improving security and to see whether they introduce new vulnerabilities. 

1.5.4 Costs, Benefits, and Metrics 

We do not know what DII COE costs. Some of the costs are borne by DISA, while other costs 
are passed on to the Commander in Chiefs, Services and Agencies (C/S/A). The DISA costs 
include support for the management process, configuration management, production engineering, 
and software development for the kernel, the Integrated Command, Control, Communications, 
Computers, and Intelligence System Framework—the COP toolkit—and some of the tools. The 
C/S/A bear the costs for staffing working groups, sponsoring new components not already in the 
COE, and migrating Mission Applications to the COE. We do not know the extent of the costs 
borne by the C/S/As. One of the key issues has been the lack of funding to bring new 
capabilities into the COE. Costs are expected to be borne by the C/S/A, but they frequently do 
not have the funds. The lack of funding is a de facto priority system—no funding means low 
priority. 

While the top-level goals for DII COE are to improve interoperability, improve functionality for 
the warfighter, and reduce life-cycle costs, there has been no effort to quantify any of these. 
Reports from Aerospace Command and Control, Intelligence, Surveillance, and Reconnaissance 
Center (AC2ISRC) indicate that they expect to spend a significant part of their funds budgeted to 
improve functionality on complying with DII COE. Of particular concern is the backward 
compatibility provided when new versions of DII COE are released. Processes which regularly 
evaluate the technical impact associated with changes in the DII COE and the benefits of DII 
COE mandates against mission impact and program costs are needed. 

1.5.5 Requirements and Mandates 

DII COE is mandated by the JTA. The JTA is promulgated by a memo dated 29 November 
1999, and signed by the Undersecretary of Defense (Acquisition, Technology and Logistics), the 
Assistant Secretary of Defense (Command, Control, Communications and Intelligence), and the 
J6 (Director, Command, Control, Communications and Computer Systems). 

Version 3.0 of the JTA states, “The DII COE, as defined in the DII COE I&RTS, is fundamental 
to a Joint System Architecture (JSA). In the absence of a JSA, the JTA mandates that at a 
minimum, all C , Combat Support, and Intelligence Systems supporting the Joint Task Forces 
and Combatant Commands will use the DII COE. All applications of a system that must be 
integrated into a DII platform shall be at least DII COE I&RTS level-5 compliant (software is 
segmented, uses DII COE Kernel, and is installed via COE tools) with a goal of achieving 
Level 8.” 


4-35 



The overall requirements process takes too long and is too inflexible. Spiral development 
demands that a trade space exist between requirements, implementation and test/certification. If 
we expect the Cost as Independent Variable approach is to be successful, and any usable 
products are to be delivered, then we must set up an infrastructure to address the overall process. 
Many communities must re-think their business activities: from the budgeting and program 
objective memorandum’ing perspective, the test and certification view, the training approach, the 
deployment mechanisms, security accreditation, etc. 

We must continue to improve installation and training technology. Parallel testing and 
certification opportunities must be exploited. Distributed configuration management is needed to 
allow developers access to software resources. The ability to easily perform regression testing 
must be in place. We must be able to fund technology initiatives as technology appears, not plan 
for its insertion years in the future. 

Finally, the users must be an integral part of this process. This means providing a consistent user 
base to guide development, with the empowerment to make decisions in the 
requirements/implementation/testing trade space. 

1.6 Recommendations 

Many of the DII COE issues described above impact multiple organizations because of the joint 
nature of DII COE. While these recommendations are addressed to the Air Force, the actions 
will involve others, particularly DISA. 

• Take charge of your own destiny. The Air Force (SAF/AQ, AC2ISRC, and ESC) must take a 
leadership position to steer DII COE to meet Air Force needs. 

- The Air Force should examine DII COE mandates and accept responsibility for providing 
waivers, where appropriate. The Designated Acquisition Authority has this authority now. 

- The Air Force should institute a process (spiral-like) to involve all affected parties in steering 
DII COE to meet Air Force needs. This includes balancing costs, operational, and technical 
needs. 

- The Air Force should ensure that the DII COE provides sufficient backward compatibility to 
meet Air Force needs, specifically for TBMCS. 

- The Air Force should develop the capability to experiment with emerging versions of 
DII COE in a testbed environment. 

• Streamline the DII COE process. The Air Force (ESC/DI) should work with DISA to 
streamline the DII COE development and compliance processes. This includes: 

- Getting out of the kernel business and moving to more reliance on the commercial sector. 

- Allowing certification of Windows-based systems to be done by complying with the 
Microsoft Logo Program to be associated with Windows 2000 Service Pack 2. Explore 
similar certification arrangements for Unix-based systems. 

- Turn the execution of DII COE compliance over to the Services and/or approved companies 
in the private sector. 

• Incorporate new technologies into DII COE. The Air Force should move aggressively (in 
conjunction with DISA) to accommodate the evolving technology base in DII COE. The goal is 
to avoid an excessive requirement and approval process. 
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- Embrace opportunities offered by web-based technologies emerging from the commercial 
sector (for example, World Wide Web Consortium) and the research community (for 
example, DARPA and Rome Labs) 

- Seek alternate ways to provide interoperability by exploiting XML and by exploiting research 
on semantic interoperability. 

Insure that mechanisms needed to support the JBI (for example, publish and subscribe) are 
identified and accommodated 

• Do cost benefit analysis for DII COE. Processes should be established which regularly evaluate 
the technical impact of changes to the DII COE and the benefits of DII COE mandates against the 
mission impact and program costs. 

• Look beyond DII COE. The Air Force needs to ensure that the appropriate processes are in 
place to evolve their command and control systems with the changing commercial and 
technology base: 

- Move from a platform (hardware and software) to a service orientation. JBI is moving in this 
direction. 

- Develop a security architecture and continuously revise it as technologies and threats change. 

- Accommodate new sources of system development, including use of scripting and locally- 
developed software. 

- In accommodating these changes, develop processes that ensure the integrity of the systems 
that are to be fielded. 
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Chapter 5 

Report of the People and Organization Panel 


5.1 Introduction 


The Air Force vision for global aerospace power is built upon a foundation of “quality people.” 

In recognition of the critical contribution of skilled, motivated people to effective command and 
control (C 2 ), the Air Force Scientific Advisory Board (SAB) study leadership formed a team to 
focus specifically on “People and Organization” issues and their implications for improvement of 
the future Air Force theater C 2 capability. The panel was asked to address a broad range of 
subject matter areas, including organizational and institutional issues, personnel practices, 
training of C 2 specialists, and human interfaces for C 2 systems. The panel members included 
technical specialists from industry and academia with expertise in various aspects of human 
factors along with retired Air Force personnel experienced in both ground-based and airborne C 2 
operations. The panel membership is listed in Appendix 5B. 

Figure 5-1 illustrates the overall scope of the effort undertaken by the People and Organization 
Panel. As shown in the diagram, the C 2 system can be conceptualized as a combination of 
resources (hardware, software, and people) that must be utilized in the right combination to 
accomplish a mission within a particular operational environment. The panel was asked to 
review current Air Force practices relative to the human factors listed in Figure 5-1 and assess 
their impact on performance and mission-effectiveness of existing C 2 systems (see Appendix 5 A 
for a complete description of the panel charter). The panel then formulated specific 
recommendations for improvements. 



Organization and Institutions 

• Vision, Values, Policies, Leadership 

• Structure, Doctrine 

• Processes 


Personnel Practices 


Skills Management 
Career Path 


• Staffing 
Training 

• Requirements 

• Content and Curricula 

• Methods and Technology 
Human System Interface 

• Requirements and Standards 

• Display and Control Media/Technology 

• System Development and Acquisition Practices 


Figure 5-1. Subject areas investigated by the People and Organization Panel 


5.2 Approach and Visits 

Because of the broad scope defined by the panel charter and limited timeframe for the 
investigation, the collection of relevant information represented a substantial challenge for the 
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study team. The panel identified and contacted organizations that could provide information on 
current problems and challenges, ongoing initiatives, and advanced concepts related to each 
subject area. Organizations identified included government agencies, military agencies, 
commercial companies, and academic institutions. These organizations were then contacted and 
briefed on the purpose and scope of the study. Arrangements were made to secure relevant 
information by means of site visits, telephone conferences, or written reports. In most cases, 
data collection involved a visit to the facility to obtain briefings or demonstrations and to 
facilitate direct interchange with resident experts in the above subject areas. Table 5-1 shows the 
organizations and facilities visited during the course of the study. 

Table 5-1. Site visits completed by the People and Organization Panel 


ACC, AC2ISRC , Network Operations Security Center.. Langley AFB 

Lockheed Martin; Boeing Info. Systems .....................................Washington DC 

U.S. Navy; the Defense Advanced Research Projects Agency 
(C 2 -related ATDs/ACTDs) Washington DC 

Air Force Fighter Weapons School/Red Flag .Nellis AFB 

C 2 Training and Innovation Group; C 2 Battlelab Hurlburt Field 

93rd Air Control Wing (JointSTARS) ..........................................Robins AFB 

Air Force Agency for Modeling and Simulation. Orlando, FL 

AFRL Human Effectiveness Directorate Wright-Patterson AFB 

AFRL Information Directorate Rome Research Site 

Air Force Electronic Systems Center......Hanscom AFB 

Boeing Phantom Works; Space and Communications. Seattle, WA 

U.S. Navy Command Ship Coronado San Diego, CA 


5.3 Findings and Discussion 

An essential prerequisite for improving Air Force C 2 is the recognition and accompanying 
organizational reinforcement of theater C 2 as a warfighting element on equal footing with all 
other combat functions. At the heart of this recognition, and built on the foundational element of 
“quality people” for the Air Force core competencies, is the establishment of a trained force of 
C 2 professionals, dedicated to operational C 2 centers. To realize the vision of C 2 as a highly 
integrated and effective weapons system, the human dimension in C 2 effectiveness must be 
addressed. The relevant human-related issues can be grouped into the following categories: 

• Institutions 

• Organization 

• Training 

• Personnel practices 

• C 2 system design 

• Human-system interface (HSI) technologies 

A discussion of the panel findings regarding each area is presented below. Specific 
recommendations are provided in Section 5.4 of this report. 
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5.3.1 Institutions 

Status, Authority, and Priorities. The absence of professional status for the “C 2 warrior” 
contributes to the low priority for staffing, resources, and funding for C 2 warfighting functions. 
As a consequence, the system defaults to improvised solutions in response to crises. Some 
elements of these problems are being addressed by Aerospace Command and Control, 
Intelligence, Surveillance, and Reconnaissance Center (AC2ISRC). However, the Center has not 
been vested with the comprehensive operational, budgetary, and acquisition authority to ensure 
that standards for C 2 operations are enforced and that acquisition and modernization are 
accomplished in a prioritized and consistent fashion across the full range of C systems. The 
paradox is that many previous studies and any number of senior Air Force leaders have 
recognized and articulated these problems and the changes needed. However, the institutional 
will to fully implement change seems to be lacking. 

C 2 as a Weapon System. In its entirety, a weapon system is composed of dedicated hardware, 
software, support logistics, facilities, personnel, doctrine, procedures, training, and various levels 
of command oversight. Ideally, a weapon system is defined by its mission and a specified 
operational capability that is described in a concept of operations (CONOPS). Historically, 
having the status of a “major weapon system” has served to focus priority, resources and 
leadership attention on the system and its enabling resources. Fundamental skill domains 
contributing to the effectiveness of weapon systems are often referred to as “core competencies,” 
enhancing their value and relevance as perceived by the general population. While the C 2 
mission area requires all of these same elements, it has not held the status or shared in the 
benefits normally accorded a traditional weapon system and its enabling competencies. 

The Air Force leadership has stated the intent to treat C 2 as a “weapon system.” The efforts 
under way to develop definitive CONOPS and operational architectures for major elements of 
the C 2 system represent important steps in this direction. Obtaining status as a true weapon 
system implies, however, that C 2 subsystems such as the Air Operations Center (AOC) will be 
characterized by certain key attributes that are not fully in place at present. Among these are 

• Personnel staffing, skill requirements, and crew duty allocations driven by CONOPS 

• Established policy for system manning levels 

• Standardized doctrine and procedures for system operation, maintenance, and support 

• Comprehensive, current, and standardized training publications, curricula, and methods 

• Required certifications supported by regular refresher training and proficiency checks 

• A system program office with overall responsibility and accountability for requirements, 
acquisition, and planned modernization 

• A structured system engineering approach to development, testing, and configuration 
management 

These attributes have very important implications for human effectiveness in C 2 operations. It is 
essential that the Air Force leadership follow through on its co mm itment to institutionalize C 2 
and the AOC as a weapon system by fully implementing these elements of the weapon system 
concept. 

Processes and Documentation. With regard to processes, considerable written guidance for the 
C 2 mission exists, but the documentation is generated through a number of independent channels 
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and is often inconsistent. For example, Figure 5-2 shows three different functional organizations 
for an AOC documented in current Air Force directives. These publications outline the 
functional organization of an AOC and specify from three to five major operations. Applicable 
documents include: Joint Publication (JP) 3-56.1 (three functional areas), Air Force Doctrine 
Document (AFDD) -2 (four functional areas), and Air Force Instruction (AFf) 13-1 Vol. 3 (five 
functional areas). These conflicting directives may inhibit standardization of the baseline AOC 
and have negative implications for staffing, training, and efficient transition from peacetime to 
wartime operations. This example also highlights a disparity between Air Force Doctrine and 
Joint publications. The establishment of a definitive baseline CONOPS, resolution of conflicts in 
directives and alignment of Air Force and Joint Doctrine should be high priorities for 
improvement of C 2 effectiveness. 


JP3-56.1 AFDD-2 



Figure 5-2. 


Disparity in AOC Functional Organizations Based on Air Force Publications 


17 , 18,19 


Acquisition Framework. The approach used in C 2 acquisition is somewhat fragmented and 
could benefit from a more coherent, integrated, user-driven strategy for developing and 
purchasing systems. The current structure involves numerous program elements and tends to be 
platform- or component-centric rather than capability-centric. For this reason, stovepiped 
systems are prevalent in C 2 , creating problems in connectivity, training, and program 
management. Further, many systems are not interoperable with other joint or Air Force C 2 
systems, contributing to less than optimum combat effectiveness. Decisive leadership will be 


17 JP 3-56.1, “Command and Control for Joint Air Operations,” 14 November 1994. 

18 AFDD-2, 17 February 2000. 

19 AFI 13-1, AOC Vol. 3, Operational Procedures-Air Operations Center, 1 June 1999. 
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required to reshape current acquisition strategies and to seek congressional support for necessary 
process improvements. 

5.3.2 Organization 

Operational Air Force C weapon systems, such as the Airborne Warning and Control System 
(AWACS), the Joint Surveillance Target Attack System (JointSTARS), Rivet Joint, the Airborne 
Battlefield Command and Control Center, and the Ground Theater Air Control System are 
equipped with advanced sensors and have access to a large body of valuable intelligence, 
surveillance, and reconnaissance (ISR) information. They have extensive communications and 
computer processing capability integrated into their architectures to enable exploitation and 
dissemination of their products. Most important, however, they have a worldwide deployment 
mission that drives their day-to-day planning and training. They prepare for combat employment 
as their primary mission. These systems train with their joint and Service component 
counterparts in regular simulation and live events, both in the continental United States 
(CONUS) and in theater. An example is the deployment of JointSTARS to support Army forces 
at the National Training Center and AWACS involvement in the Navy’s Fleet Battle 
Experiments. In addition, operational C 2 units run robust daily training programs for the initial 
qualification and upgrade of their personnel. 

Only at the top level of our CONUS-based theater C 2 , the AOC, are part-time operations the 
norm, with key personnel performing C 2 duties as an adjunct to their primary staff assignments. 

A review of Blue Flag lessons learned reveals shortcomings in this approach to providing C 2 
warfighting capability to the Combat Air Forces. The AOC’s elements, assigned to the CONUS- 
based numbered air forces (NAFs) are only partially staffed. At best, they train as a system 
annually during Blue Flag. They may augment their supported theater commander in chief 
(CINC) during annual training cycles, but augmentees are widely recognized to be less than 
knowledgeable upon arrival in theater and in need of orientation and refresher training. Standing 
AOCs (Operation Southern Watch, Operation Northern Watch, the Combined Aerospace 
Operations Center [CAOC] at Vicenza) operate with only a handful of permanent staff; 
additional staff rotate every 90 to 120 days. With the onset of a crisis, staffing ramps up rapidly 
but in an ad hoc fashion, in part because the personnel system does not support ready 
identification of certified personnel. 

Training, manning, and modernization initiatives are all driven by organizations. The current 
NAF AOC lacks the structure to implement solutions. A potential solution lies in establishing 
standing NAF AOCs as full-fledged participants in the C 2 structure. Establishing a full-time 
operational AOC at a designated NAF could solve a number of C 2 problems. Most important is 
the placement of responsibility for training and equipping directly in the hands of a single agent. 
Management of this unit, its employment and tasking would become a primary responsibility for 
a designated NAF commander. Critical modernization would be initiated and championed by a 
single agent acting as principal sponsor for AOC upgrades and standardization. Coordination 
with the Air Staff, Electronic Systems Center, and the AC2ISRC would be managed through the 
tasked NAF commander. 

To effectively support an Aerospace Expeditionary Forces (AEF), there must be a comparable 
AOC element trained and ready to deploy to support it. The C 2 NAF concept provides a 
management vehicle that can support the AEF while also managing the low density/high demand 
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(LD/HD) ISR assets. As each AEF comes into its scheduled rotation window, the NAF AOC 
would identify the AEF team scheduled for deployment. Qualification and upgrade training 
would be scheduled and managed by the personnel on alert, designated by name. The alert team 
would align with the alerted ISR resources to ensure effective integration of these elements from 
day one of any action. Current ad hoc taskings to support contingencies should be minimized 
and in-theater lag time reduced. 

A final benefit from this concept is that each theater CINC would have fully trained and 
experienced C professionals dedicated to support combat operations in theater. Support to 
standing AOCs, such as the CAOC, would be provided by designated teams. Blue Flags and 
annual theater exercises would be supported with personnel specifically trained in the AOC’s 
processes and procedures. 

5.3.3 Training 

The Air Force does not have in place a fully trained force of C 2 professionals in sufficient 
numbers to respond efficiently to the demands of a major theater crisis. Air Force leaders lack 
the necessary training and experience to develop the full complement of essential warfighting 
skills, particularly at the operational level of command. The current approach to C 2 training does 
not support the “train the way you fight” doctrine and has not been fully integrated with the 
Expeditionary Aerospace Force structure and duty cycle. Resources and priorities for C 2 training 
are not comparable to other weapon systems, and the opportunities to gain necessary skills and 
experience are therefore limited. C 2 duties are not practiced routinely in peacetime and are often 
shared with staff assignments. These staff responsibilities often take precedence over scheduled 
C 2 training opportunities, since performance in these staff positions, rather than warfighting 
skills, is seen as the basis for promotion. 

Air Force personnel assigned to other weapon systems normally experience an orderly 
progression of training from basic military training (Officer Training School [OTS], Reserve 
Officer Training Corps [ROTC], etc.), through undergraduate training (Undergraduate Navigator 
Training, Undergraduate Pilot Training, basic maintenance officer, etc.), to specialized training 
(FTU, etc.) that leads to initial qualification and mission-ready status. These efforts are managed 
carefully to include testing and certifications along the way and then are periodically revisited to 
assure currency and proficiency. Such is not the case for C 2 specialists today. Because C 2 lacks 
status as a weapon system, formal training is more often acquired in a less structured fashion, 
often through on-the-job training. This largely ad hoc approach to training produces too few 
senior C 2 professionals with the complete skill set and qualifications to serve effectively as 
mentors. 

The Air Force does have in place certification requirements for C specialists and training 
directives (AFI 13-109, Vol. I) that mandate required training. Well-designed and -administered 
C 2 courses and training programs are also available at Maxwell Air Force Base (AFB), Nellis 
AFB, and Hurlburt Field. Collectively, these programs constitute a large proportion of the 
necessary academic content to support a professional C 2 warrior force (see Appendix 5C for 
course descriptions). While a relatively complete training curriculum exists, only about 
20 percent of AOC personnel have actually completed the “mandatory” training required for 
certification in their individual specialties. The part-time nature of C 2 assignments, combined 
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with staffing shortfalls and failure to fully utilize existing training opportunities, creates a 
downward spiraling effect—fewer opportunities supported by fewer people. 

Integration of ground-based C 2 into the major weapons school exercises is lacking, as is the 
presence of interactive and adaptive AOC functions in Red Flag. Even the dedicated venues of 
Blue Flag have evolved into qualification events centered around Air Tasking Order (ATO) 
production instead of operational exercises that strengthen C 2 skills. This is primarily because 
participants are temporarily assigned on an ad hoc basis from their staff positions without the 
benefit of adequate preparation or daily C 2 operations. At the higher levels, the Joint Force Air 
Component Commander (JFACC) and AOC Director often have their first experience in these 
roles with the advent of a crisis. The end result is a lack of sufficient numbers of fully trained, 
professional C 2 leaders, at all levels, to staff and execute the warfighting functions of the AOC. 
Some of the specific training challenges that impact C 2 effectiveness may be summarized as 
follows: 

• The need to prepare future C 2 leaders to move from being ATO generators and managers to 
become commanders of aerospace forces 

• Difficulty in delivering the right training to the right person at the right time 

• Limited ability and opportunity for units at all levels (air component and operational unit) to 
provide job qualification training and continuation training 

• Lack of standardization of procedures and processes within and across major weapon systems and 
functional communities 

• Lack of a structured method for presenting and completing standardized, accessible training 
products and materials at the point of delivery 

• Lack of an ability to track and monitor availability and status of personnel with critical skills to 
support AOC and AEF operations (for example, targeting, collection management, ISR 
operations, airspace battle managers, SIDO and FIDO) 

• Inability of personnel to attend critically needed training due to high operations tempo and 
personnel tempo 

• Reductions in availability of centrally funded training and quotas for school slots 

• Lack of an enterprise-wide skills management system to provide visibility at all levels into force 
readiness posture 

• Lack of opportunity for daily AOC training and operations comparable to other systems and 
functions 

Theater C 2 training and readiness could be strengthened through the development of clearer and 
more concise training requirements based on the C 2 /AOC CONOPS and Mission-Essential Task 
Lists (METLs). CONOPS-driven training requirements can, in turn, provide a solid foundation 
for improving training content, curricula, and methods. In addition to formal training for C 2 
specialists, C 2 training must be included in basic military training for all Air Force specialties. 
Opportunities to obtaining this foundation of basic C 2 principles include professional military 
education (PME) and the basic courses for various occupational specialties (for example, the 
maintenance officer course and initial qualification in nearly all weapons systems). These 
training improvements must be supported by an expanded skills tracking and management 
system to fully exploit their benefits (see Section 5.3.4). To enable and honor the “train as we 
intend to fight” doctrine, C 2 must become an integral component of nearly all Air Force 
operations-oriented training programs. 
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5.3.4 Personnel Practices 

There is a widely held belief among Air Force personnel that C 2 skills and experience are not 
valued assets for career advancement. Indeed, there is a common perception that assignment to 
an AOC is a career dead end. The C 2 community suffers from the absence of a defined and 
viable career path, the lack of adequate rewards, and recognition for C 2 experience, and the 
inability to attract and retain high-quality personnel as core C 2 specialists. Personnel representing 
other functional domain expertise tend to avoid excursions into C 2 assignments and lack 
exposure to fundamental C 2 principles, further limiting the pool of talent available to augment 
core C 2 staff in time of crisis. To solve these problems, the Air Force must establish a 
recognized “C 2 warfighter” career track. Career promotions and incentives must better reward 
the skills and expertise of the C 2 warrior to attract and retain qualified individuals. 

Skill and experience requirements for C 2 warriors and for AOC positions are not well defined or 
documented. In time of war, the AOC staffing problem is further compounded by difficulties in 
tracking skilled professionals in the current personnel system due to lack of adequate experience 
identifiers. Consequently, contingency-driven staffing requirements result in a pick-up solution 
that is slow to reach critical mass and is heavily dependent on ad hoc, on-the-job training. 
Today’s personnel tracking system must be improved to rapidly and accurately identify 
personnel who have the necessary skills, experience, and certifications to staff essential AOC 
functions. 

An expanded, enterprise-wide tracking system is needed to better manage the human resources 
and provide the mechanism to develop and deliver standardized, approved training to the right 
person at the right time. Such a system would also enable functional and force managers to gain 
insight into the progress, status, and level of effort across the force, including critical skill sets. 

It would also provide access to distributed databases, including 

• Skills management (tracking certification status of critical skill sets—initial qualification training 
(IQT), mission qualification training (MQT), and continuation training (CT) 

• Personnel management and record keeping 

• Input for training curriculum development 

• Virtual classroom (on-line conferencing and collaboration tools) 

• Knowledge capture (digital library for reference and reuse) 

Efforts are under way at the AC2ISRC to augment the personnel tracking system. Specific 
complementary functions offered by this expanded skills management system concept could 
include 

• Ability to identify and validate C 2 personnel training requirements from the unit level up through 
the AOC level in a virtual collaborative work environment 

• Ability to deliver courseware and distributed learning by means of a virtual institute or campus 
using Web-based technology 

• Ability to document and track training accomplishments for designated active-duty and reserve 
component personnel to support AEF/AEW and AOC personnel requirements management 

• Ability to track certifications to satisfy identified personnel qualification and certification 
requirements for critical skill sets 
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Ability to provide automated force readiness status based on established metrics for commanders 
at all levels 




5.3.5 C 2 System Design 

Arguably, there is no other warfighting function where the HSI is more important than in C 
because of the volume, complexity, importance and time-critical nature of decision making 
required. As shown in Figure 5-3, the effectiveness of the HSI is also a key element in 
establishing a “common operational picture,” which, in turn, is essential for collaborative 
decision making and interoperability across organizations and platforms. 
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Figure 5-3. The Human-System Interface Contribution to Interoperability 


The study team reviewed and assessed current Air Force practices for assuring effective human- 
system integration in acquiring and modernizing C 2 systems. The panel was briefed on the 
processes used in developing and testing of several representative airborne and ground-based 
systems that play key roles in theater-level battle management. These included the Theater 
Battle Management System (TBMCS), JointSTARS, AWACS avionics upgrades, and the Multi- 
Source Tactical System. The panel also received briefings or documentation on the HSI 
integration approach in use for current Air Force combat aircraft development and upgrade 
programs (for the F-22, B-1B, and C-130). The scope of these briefings and discussions 
included definition of HSI requirements, function allocation, crew complement and workload, 
HSI design, accommodation of user preferences and physical characteristics, performance 
metrics, and test methods. 

In general, it was found that the priority assigned (and resources provided) to ensure effective 
HSI in C 2 systems is low in comparison to other weapon systems. While the Air Force has 
recognized the impact of HSI design on mission effectiveness of combat aircraft (for example, 
the F-22 and Joint Strike Fighter), there seems to be comparatively little awareness or 
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appreciation for the value of a well-designed human interface for the decision support systems 
that enable effective C 2 . Some problems associated with the present Air Force approach to the 
HSI for C systems may be summarized as follows: 

• Lack of definitive CONOPS to serve as a basis for design and testing of the HSI 

• Lack of a systematic process for definition of HSI requirements and metrics 

• Inadequate or late involvement of operational users in system development (particularly leaders 
and commanders) 

• Failure to establish or apply standards to ensure HSI consistency within and across systems and 
platforms 

• Failure to fully exploit available HSI technologies and decision support tools 

• Lack of definitive performance criteria for HSI effectiveness 

• Insufficient human engineering capability (trained staff and facilities) within product centers for 
C 2 systems 

While the panel found some examples of sound HSI design practices (for example, the AW ACS 
and C-130 avionics upgrades), their application across programs has been inconsistent. In some 
cases, this has resulted in user interfaces that are unnecessarily complex, counter-intuitive, and/or 
difficult to learn. While the magnitude of the effect is difficult to estimate, these deficiencies 
undoubtedly have a negative impact on user workload and productivity as well as on the 
timeliness and accuracy of decisions and actions. These factors will in turn have negative 
implications for other personnel issues, such as staffing and training. 

It seems clear that the Air Force could benefit substantially from the application of a more 
rigorous approach to the design and testing of the HSI for C 2 systems. The necessary 
knowledge, methods and tools are already in use in other Air Force weapon system applications. 
If an effective human engineering program for C 2 systems is undertaken early in the acquisition 
cycle, the costs of implementing it are minimal relative to the potential performance 
improvements. 

The Office of the Secretary of the Air Force has acknowledged the need for increased emphasis 
on human-system integration. In a recent memorandum to the Air Force leadership, 

Lt Gen Stephen Plummer (SAF/AQ) stated, “Integrating the human into the early development 
of all Air Force acquisitions is a critical component to increasing operational effectiveness, 
minimizing follow-on modifications and reducing life cycle cost. The acquisition community 
must engage HSI more effectively early in the acquisition process.” 20 While this statement 
represents an important first step, it is essential that the Air Force acquisition leadership put in 
place the necessary process, resources, and infrastructure to ensure that these goals are realized. 
Section 5.4.5 provides specific recommendations regarding the establishment of an improved 
process for human-system integration and the essential mechanisms for institutionalizing this 
process in the acquisition of Air Force C 2 systems. 

5.3.6 Human-System Interface Technologies 

The panel reviewed HSI technologies and their applications in current Air Force C systems. 

The panel concluded that the Air Force has not fully exploited HSI technologies, automation, and 

20 Memo from SAF/AQ, Lt Gen Stephen B. Plummer, Principal Deputy Assistant Secretary of the Air Force 
(Acquisition), entitled “Awareness of Human Systems Integration in Air Force Acquisition,” June 2000. 
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decision support tools that are available or under development for other applications. This 
finding is consistent with the conclusions reached by the Technology Panel, which found that a 
number of useful HSI concepts in use in the co mm ercial sector and Department of Defense 
(DoD) have yet to be applied to Air Force C 2 systems (see Chapter 4). The People and 
Organization Panel then assessed advanced HSI technologies and concepts for potential C 2 
applications. For the purposes of this study, the panel confined its assessment of HSI 
technologies to those available in the relatively near term (the next 5 years). The reader may also 
find useful a more comprehensive review of HSI technologies provided in Volume 2 of the 1999 
SAB Study on the Joint Battlespace InfoSphere 21 . 

Table 5-2 summarizes the HSI technology assessment. The table includes concepts in use or 
under development in the private sector, as well as those from other DoD applications. The table 
also highlights some potential operating benefits to be realized and a projection of technology 
availability. Recommendations regarding several of the most promising HSI technology 
applications are described further in Section 5.4.6. 


21 SAB-TR-99-02, “Building the Joint Battlespace InfoSphere, Vol. II: Interactive Information Technologies,” 
17 December 1999. 
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Table 5-2. Assessment of HSI Technologies for Potential C 2 Applications 


Technology 

Application 

Benefits 

Availability Date* 

Controls & Displays 

Automatic speech 
recognition 

AOC 

Faster spinup time for augmentees 

ATO created 30 percent faster 

Reduced training time overall 

Now, for TBMCS 
application 

6 months for other 
applications 

Wearable displays 

AOC; training; 
personal gear; 
intelligence; 
operations; etc 

Several wearable design options (wrist, 
knee, chest, around neck, on head) 
allow hands-free mobile display viewing 

See also “portable displays” 

Now, for some 
applications 
(Commercial-off-the- 
shelf available) 

Augmented 
reality—incorporate 
real-time view of 
battlefield and 
record 

Intelligence; planning 
and wargaming; 
rehearsal; operations; 
training 

Better situation awareness through 
synthetic enhancement of the live 
battlespace; reduces pattern 
recognition uncertainty 

1 year (non-immersive) 

Immersive reality 

Intelligence; planning 
and wargaming; 
rehearsal; operations; 
training 

Intuitive, high-fidelity simulation of the 
battlespace improves transfer of 
training, reduces pattern recognition 
uncertainty 

Now, for training 

3-6 years for C 2 
systems 

Volumetric displays 

Intelligence; planning 
and wargaming; 
rehearsal; operations 

Intuitive, high-fidelity representation of 
the battlespace reduces pattern 
recognition uncertainty 

2-3 years for true 3-D 
symbols and graphics; 

4-6 years for complex 
scene-filling true 3-D 
images 

Stereoscopic 

displays 

Intelligence; planning 
and wargaming; 
rehearsal; operations 

Improves spatial decluttering; reduces 
pattern recognition uncertainty 

Now 

3-Audio 

AOC 

JointSTARS 

AWACS 

Voice communication with more people 
and lower rates of confusion 

Now 

Untethered C 2 

(magnetic sensing, 
infrared, etc.) 

AOC 

Ability to use display technologies, for 
example, data wall, without physical 
constraints 

4-6 years; depends on 
technology; see 
“portable displays” 

Large screen 
seamless projection 
supported by a 
multiheaded display 
driver (2 to 20 
display units driven 
as a single ultra- 
high resolution wall- 
size display 
system) 

AOC 

More flexible display configuration; 
ability to review more data 
simultaneously 

1- 3 years; now— 
knowledge wall 
demonstrated Aug 2000 
on U.S.S. Coronado 
(10 ft tiled with 1- to 

2- in. seams); seamless 
overlapping image tiled 
designs demonstrated 
at Honeywell, Sarnoff 

Portable displays, 
palmtops, and 
tablets flexible 
displays 

AOC 

Personal gear 

Continued connectivity while in transit; 
lightweight, reconfigurable workspace 
options 

Now—5 years with 
unclassified networks; 1 
to 5 yrs with classified 


Technology availability date = approximate timeframe when the technology could be used in an operational system. It is assumed 
that initial prototypes of each technology would be deployed rapidly, with block upgrades to follow. 
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Technology 

Application 

Benefits 

Availability Date* 

Controls & Displays 

Touch-sensitive 
displays (any size) 
coupled with 
gesture and 
handwriting 
recognition 

AOC 

JointSTARS 

AWACS 

Faster, more intuitive entry of graphical 
data; enables reprogrammable buttons; 
more natural collaboration with large- 
screen displays; provides keyboard 
functions for portable displays 

Now 

Flat panel displays; 
AMLCD, DMD, EL, 
OLED, ETC. 

AOC; all C 4 ISR 
applications; 

JointSTARS; 

AWACS, Airborne 
Laser 

Better situation awareness, higher 
resolution than CRTs; lighter weight, 
more reliable and smaller footprint 
terminals; less power 

1-3 years for AMLCD, 
DMD, EL; 3-5 years for 
OLED 

Ultra-thin clients for 
client-server 
architecture 
coupled with flat 
panel displays 

AOC 

JointSTARS 

AWACS 

Lighter-weight user terminals; ease of 
workspace reconfiguration for custom 
team collaboration 

Now 

Biometrics 

AOC 

Improved security in user identification 
(see smart card) 

2 years 

Smart card user 
identification 

AOC 

Rapid, consistent logon and 
configuration of desktops; custom 
desktop and network permissions travel 
with user 

Now 

Visualization 

Perspective view of 
the battlespace 

Planning, 
intelligence, and 
operations 

Better situation awareness; reduced 
uncertainty in pattern recognition; 
supports faster, more reliable decision 
making 

1 year 

Layered imagery 

Planning, 
intelligence, and 
operations 

Better situation awareness; reduced 
uncertainty in pattern recognition; 
supports faster, more reliable decision 
making 

Now-for limited map 
and imagery products 

Logistics control 
and information 
support (LOCIS) 

Wing log C 2 

Customizable and adaptive dynamic 
user interface that allows holistic view 
of fused information to support wing- 
level operations 

2 years 

Realistic icons for 
commanders 

C 2 -wide 

Better situation awareness; reduced 
uncertainty in pattern recognition; 
supports faster, more reliable decision 
making 

Now 


Technology Availability Date = Approximate timeframe when the technology could be used in an operational system. It is 
assumed that initial prototypes of each technology would be deployed rapidly, with block upgrades to follow. 
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Technology 

Application 

Benefits 

Availability Date* 

Decision Support Systems 

Bed-down critic 

Logisticians 

Faster bed down; Intelligent agents 
catch unintended negative 
consequences of plan changes 

3 years 

Uncertainty 
management using 
Bayesian 
inferences 

AOC 

Better decisions; ability to gauge the 
quality of inputs into the decision 
process. 

3-5 years 

Communication 
workarounds; 
provide or model 
communication 
routes and 
constraints 

c 2 

Interoperability; faster message 
dissemination, fewer missed handoffs. 

4-6 years 

Proactive collection 
plan display 
(predictor displays; 
what if s) 

AOC 

Faster replanning. Anticipate what will 
happen next in a collection plan, instead 
of fixating on the information that is 
already gathered and becoming 
obsolete. See the consequences of 
changing the collection plan. 

4-6 years 

Recall campaign 

JFACC 

Rapid dissemination of changes to an 
ATO, to tighten up the decision cycle 
during replanning—for example, if 
targets are destroyed, a “recall 
campaign” will quickly notify the affected 
parties. 

4-6 years 

Team calibration 
(intent) (distributed 
systems) 

C 2 

Fewer coordination surprises; support 
distributed teams for planning and 
executing together, without requiring 
lengthy video teleconferencing. 

Now 

Overall campaign 
progress 

C 2 

Allow planners to review the data used 
to estimate progress toward objectives 
for better replanning. 

4-6 years 

Work-centered 
decision support 
using intelligent 
agents 

Air Mobility 
Command’s Tanker 
Airlift Control Center 

More accurate and robust decision 
making for airlift planning, scheduling, 
and operations. More timely problem 
identification and resolution. 

Initial versions-now 

Advanced versions-in 

2-3 years 

AOC process 
information capture, 
recall, and reuse 

AOC 

System captures audio and video of 

AOC actions. This rich dataset is then 
indexed and correlated to screen 
captures of the datawall and individual 
workstations. This will allow “instant 
replay” of AOC actions and provide the 
data to develop improved decision 
support tools and C 2 training. 

Now 

LOCIS 

Wing-level decision 
makers 

Provides proactive decision support 
through the use of customizable 
intelligent agents monitoring critical 
information based on thresholds and the 
use of a desktop simulation to provide 
what-if capability. 

2 years 


Technology Availability Date = Approximate timeframe when the technology could be used in an operational system. It is 
assumed that initial prototypes of each technology would be deployed rapidly, with block upgrades to follow. 
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Technology 

Application 

Benefits 

Availability Date* 

Training Hardware/Software 

Aerospace 
operations/training 
suite initiative 

C 2 for ISR 

Solves latency issues surrounding C 2 
responsiveness issues of ISR assets, 
increases situational awareness to 
maintain positive control over ISR 
assets, supports data fusion and data 
morphing, and integrates air and space 
ISR mission training and rehearsal 
architectures. 

4-6 years 

Brief/debrief system 

c 2 

Allows weapons directors to integrate 
information during distributed mission 
training (DMT)—C 2 brief/debrief events. 

1-2 years 

Human 

performance 

modeling 

C 2 

Improves realism of C 2 training through 
accurate representation of human 
decision-making processes. 

3-5 years 

MCE interface with 
DMT/JSAF 

MCE 

STEs 

JSTEs 

DMT 

Other C 2 Platforms 

• DMT and JSAF provide higher 
fidelity training 

- Realistic aircraft maneuvers 

- Immediate kill removal 

- Rapid generation and archival of 
training scenarios for specific 
instructional objectives with JSAF 

- Manned DMT cockpits provide 
communication practice 

- DMT provides opportunity to train 
as part of the combat team in the 
JSB 

- JSAF does not require simulation 

“drivers”; this should result in 
reduced manning 

• Training from home unit via DMT 
results in cost savings on temporary 
duty and reduced scheduling 
conflicts 

• Interface creates the potential to 
expand to include STEs/JSTEs and 
training with additional C 2 platforms 
via DMT 

• Reduced training time anticipated 

• Expands DMT- C 2 to include 
operational equipment 

If existing DIS/CD2 
converter can be 
located, immediate 
solution 

If DIS/CD2 converter 
has to be developed, 7 
months from receipt of 
funding 

Virtual Tactical 
Operations Center 

Army and Air Force 
intelligence training 

Web-based virtual environment for 
training C 2 warfighter and information 
superiority mission rehearsal scenarios 

Now 


Technology Availability Date = Approximate timeframe when the technology could be used in an operational system. It is 
assumed that initial prototypes of each technology would be deployed rapidly, with block upgrades to follow. 
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5.4 Recommendations 


5.4.1 Institutions 

Without establishing the foundation of strong institutional value for theater C , most of the other 
actions recommended in this study will enjoy little sustained impact. Theater C 2 must be elevated 
in status, representation, and resources (both personnel and funding) to the levels appropriate for 
an essential warfighting function. The following actions are considered essential in establishing 
an appropriate level of visibility and priority for C 2 in the Air Force culture: 

• As an initial step, the Air Force leadership should strengthen C 2 in its vision statement and long- 
range planning to clearly identify C 2 as the fundamental integrating function for commanding 
aerospace power. 

• The Air Force should establish an Air Staff leadership position with the responsibility and 
authority to operationalize C 2 , establish the AOC as a weapons system and ensure overall C 2 
integration. The Air Force must define all aspects of the weapon system and assign clear 
responsibility for their implementation and support. 

• The panel strongly supports the completion and implementation of the draft Air Force C 2 
CONOPS. It is essential that the Air Force follow through on this initiative, resolve 
inconsistencies in current documentation, and ensure that the baseline CONOPS is used in a 
disciplined fashion to standardize doctrine, procedures, staffing, and training for C 2 systems. 

• C 2 -related program elements must be consolidated (to a minimum number) to enable more 
effective integration and oversight of requirements, plans, investment strategy and priorities, and 
interoperability standards across the full spectmm of C 2 systems. 

5.4.2 Organization 

The principal recommendation regarding C 2 organization is to stand up daily, under the 
leadership of the Air Combat Command (ACC) C 2 operational commander, the necessary forces 
to provide C 2 operations, training, and integration for all warfighting systems. The 
organizational construct is illustrated in Figure 5-4. This “standing AOC capability” would link 
ISR and battle management forces for daily operations and training. Strike assets would operate 
off an ATO or “ATO-like” order generated by the standing AOC capability and would link to 
such AOC entities in Flag and joint exercises. The goal is to make the transition from peace to 
war as seamless as possible. 
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Figure 5-4. The C 2 NAF Concept 


The intent of this organizational concept is to operationalize the CONUS AOC activities and to 
increase the priority of the C 2 warfighting system by making it the principal responsibility of a 
CONUS NAF commander. This commander should report directly to the senior ACC 
operational commander. The commander would provide not only principal parts of the standing 
AOC capability, but also management of the LD/HD C 2 and ISR assets of the information 
operations and information warfare resources. The C 2 NAF would be organized to align core 
AOC personnel in parallel with each AEF for rapid deployment if needed. Staffing and 
assignments would align with the functions of the AOC CONOPS, consistent with the personnel 
manning documents, and would rely on a mix of active-duty, reserve, guard, and civilian 
personnel. The C 2 NAF would also be responsible for developing AOC operational standards 
established for the functions defined in the AOC CONOPS. The standards would provide a 
baseline capability of common AOC functions while accommodating tailored aspects needed for 
specific regional deployments. Supporting the C 2 NAF would be the three key organizations 
noted above and in Figure 5-4, but in this construct they would be specifically detailed to the C 2 
NAF. Other NAFs and AOCs would maintain the level of C 2 emphasis deemed necessary by 
their commanders. 

Implementing a single NAF AOC organizes existing training, experimentation, and operational 
elements into a cohesive, focused organization. This essentially converts three related but stand¬ 
alone elements into a single functional, cross-supporting unit. Training at all levels would be 
centralized at the existing Hurlburt Field C 2 Training and Innovation Group (C 2 TIG). The 
operational element at Langley AFB, previously designated as AOC Rear, becomes the daily 
functioning Operational Support Center. Experimentation focuses on the C 2 laboratory element 
at Nellis AFB executing the task of prototyping and evaluating new equipment and concepts 
before transition into the employment and training areas. The C 2 Battlelab and the Air Force 
Research Laboratory (AFRL) should work collaboratively to support this process by maturing 
promising technologies and demonstrating their readiness for transition. A single NAF AOC 
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provides the structure to coordinate actions between mutually supporting elements. It will also 
increase the quality of support provided to the standing theater AOCs and the AEFs. 

5.4.3 Training 

A critical element in moving toward “C as a weapons system” is the implementation of training 
programs comparable to those for other weapon systems. Training requirements, curricula, and 
performance standards should be derived from approved CONOPS and the METL for C 2 . The 
Air Force should establish a conventional training program for the C 2 /AOC weapons systems to 
include the necessary qualification tests and certifications to ensure proficiency and currency. 

Air Force Major Commands (MAJCOMs) should be charged with ensuring compliance with all 
C 2 training requirements and directives. Commanders should make C 2 training accomplishment 
a part of normal reporting to higher authorities. Any AOC with an operational plan commitment 
should report training status to the applicable air component and theater CINC J-3. MAJCOM 
Inspectors General should inspect units responsible for C 2 and report capability (including 
training) based on applicable METFs. 

A “standing AOC” capability should be established and charged with conducting daily 
operations and training missions in peacetime. ACC and Joint Forces Command should stand up 
the necessary forces daily to provide training and operational practice for all basic theater C 2 
functions. ISR and battle management forces should link with an AOC or “AOC-like” entity for 
daily training. Strike assets should operate from an ATO or “ATO-like” order and link to an 
AOC for Flag and CINC-directed exercises. AOC(s) should be used to drive force-level CT, 
composite force training, exercises, advanced tactical training (Weapons School/ME), and 
experimentation. These training initiatives should include measurable training objectives for the 
appropriate level of C 2 activity. To the extent possible, actual operational links should be 
established with the next layer of C 2 nodes and between other represented functional activities 
(creating horizontal and vertical integration). 

C training should be tied to AEF spin-up and reconstitution training cycles. As specific rotation 
schedules are established for the AEFs (including FD/HD assets) and the specific training 
requirements for those forces are specified, two aspects of C 2 training must be included. First, 
the entire force (operations, support, force protection, communications, etc.) should include C 2 
training and should practice the use of their respective C elements daily. Second, the C 
specialists from the Squadron Operations Center, the Wing Operations Center and the personnel 
who will support the forward AOC should all receive a commensurate level of spin-up C 2 
training and should practice their specific C 2 functions regularly. 

The Air Force should actively explore the feasibility and practical utility of using DMT concepts 
and technologies to enhance the quality and availability of C 2 training and fulfill the goal of 
“training the way we intend to fight.” Advanced DMT concepts exploit emerging weapon 
system connectivity, in combination with advanced simulation and modeling technology, to 
enable real-time collaborative operations among geographically separated systems. DMT 
technologies offer the potential to blend real, virtual, and constructive environments to produce a 
high-fidelity training experience tailored to the mission need and resource constraints. As DMT 
capabilities expand to mirror the operational environment, the distinction between training and 
operational domains will be systematically reduced or eliminated. Only the specific objectives 
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and outcomes of a particular application will dictate use of the weapon system, the simulator, 
and/or the constructive models as these become largely interchangeable tools. 

As outlined in the 1999 SAB study on Operations Other Than Conventional War, 22 these higher 
levels of integration enable development of a Dynamic Mission Readiness Environment 
(DMRE) that can perform additional functions beyond that of distributed training. These 
technologies can be used to support a wide range of functionality, including experimentation, test 
and evaluation, tactics development and validation, operations, safety assessment, and risk 
management. DMT and DMRE offer the potential to greatly improve the vertical and horizontal 
integration of C 2 and AOC-level activities with those at the wing and squadron levels, providing 
the capability for daily immersion in the dynamic operational environment. This advanced 
capability should be pursued in an incremental, spiral fashion concurrent with other ongoing C 2 
initiatives. 

5.4.4 Personnel Practices 

A comprehensive effort to strengthen C 2 professional career development should be instituted in 
the Air Force with principal responsibility assigned to AF/XO and AF/DP. Figure 5-5 identifies 
the major elements that must be in place to establish and maintain a viable force of professional 
C 2 warriors. 



Figure 5-5. Elements Enabling the Professional C 2 Warrior Force 


The first step is development of the professional warfighter career track. The AC2ISRC efforts 
in the C 2 warrior focus area for career path development are in line with this step, but we urge 
the expansion of current thinking to institutionalize the “aerospace warfighter track” illustrated in 
Figure 5-6 as a distinctive career path within the Air Force. 


22 

SAB-TR-99-01, Technology Options to Leverage Aerospace Power in Operations Other Than Conventional War, 
Vol. 1: Study Summary , February 2000; information on DMT is on pp. 10, 52-55. 
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Figure 5-6. The Professional Aerospace Warfighter Track 


In addition to notionally defining the professional C warfighter career track, Figure 5-6 
highlights the facts that the advancement opportunities would be clear to all and that visible 
equivalency with the staff track for advancement would be institutionalized. It is further 
recommended that all Air Force personnel receive some foundation in fundamental aerospace 
warfighting principles, including C , as part of their basic education at the entry level. A 
requirement should also be established for formal C 2 training or experience as a prerequisite for 
promotions above Lieutenant Colonel. Establishing fully functional AOCs and the expansion of 
training opportunities recommended in Sections 5.4.2 and 5.4.3 would greatly facilitate the 
realization of this career path alternative. 

A second critical step is the expansion of personnel data management to establish an enterprise¬ 
wide qualification tracking system that supports education and training, maintains personnel and 
training records, and provides the personnel code designations at a level sufficient to rapidly 
identify the C 2 skill set of individuals. Again, the AC2ISRC has initiated an effort to at least 
clarify and expand the Software Engineering Institute codes. This initiative should be endorsed 
but extended further to enable complete and efficient access to the databases on personnel 
management, special skills, and training and to other relevant databases. A comparison of the 
existing personnel tracking scheme and the expanded skills management framework is presented 
in Figure 5-7. 
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Figure 5-7. Expanded Capability for Tracking of Personnel Skills and Experience 


For the above measures to be effective, they must be supported by an incentive structure that 
provides tangible evidence of the value and priority assigned to C 2 by the Air Force leadership. 
Promotion opportunities for C 2 specialists must reflect the importance of the jobs they perform 
and the level of competence with which they execute their jobs. Some possible actions to 
strengthen the perceived value of C 2 include 

• Explore the Chief of Staff of the Air Force “contribution-based pay” initiatives such as 
professional warfighter pay for qualified colonels similar to medical pro-pay and the aviation 
continuation bonus (that is, implementation for all functional domains, including C 2 ) 

• Provide promotional opportunities honoring the premise that “all warriors are created and treated 
equal” (that is, a parallel to joint assignment and promotion potential initiatives) 

• Make career advancement and/or preferred assignments contingent on C 2 training, experience, 
and qualifications 

• Re-orient the bonus system to reward qualified volunteers for hard-to-fill, remote, and/or hardship 
assignments 

• Establish a course or program of weapons school caliber that results in a specialty designation for 
key aerospace command positions and enhanced promotion opportunities for graduates 

In combination with the improved training opportunities and daily operations, these measures 
provide the foundation upon which a professional C 2 warrior force can be built and maintained. 

It is essential to note, however, that all of the elements identified in Figure 5-5 are inter¬ 
dependent and must be addressed in a balanced, coordinated fashion to realize the desired results. 

5.4.5 C 2 System Design 

Effective integration of operational experience and human engineering design principles must be 
accomplished early in the HSI development process, since they often impact architectural and/or 
software design decisions that are prohibitively expensive to change at later stages of 
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development. For this reason, a structured, systems engineering approach, comparable to that 
employed routinely in the development of the HSI for combat aircraft, should be applied in the 
acquisition and modernization of future C 2 systems. 

Figure 5-8 shows an example of a process for improved human-system integration. The diagram 
shows a fundamentally mission-driven approach, with requirements, functions, operator tasks, 
and performance metrics all derived directly from (and traceable to) the mission. This process 
also heavily emphasizes user involvement at all stages of system development and testing, using 
rapid prototyping and part-task simulation tools to actively engage users in assessing alternatives 
and evaluating operational utility as the design evolves. The iterative nature of this approach is 
entirely compatible with spiral development and provides for effective transition from 
development to operations, sustainment and incremental upgrades. 
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Figure 5-8. Human-System Integration Development Process 


Several actions should be assigned by SAF/AQ for implementation by the Air Force Materiel 
Command and its product centers to institutionalize this type of systems approach to HSI 
integration in the acquisition process. These include 

• Establish a stmctured process like that in Figure 5-8 to ensure effective HSI integration 

• Establish usability goals as key performance parameters 

• Include HSI effectiveness criteria in the source selection process 

• Tailor and apply Military Standard 1472 and Military Handbook 46855 as appropriate 

• Recommend establishment of HSI compliance criteria and processes for Defense Information 
Infrastmcture Common Operating Environment certification 

• Require training in HSI for program managers (similar to the U.S. Army MANPRINT program) 

An important action for the ACC C 2 operational leadership is to define a reference mission and 
baseline CONOPS prior to the initial cycle in the spiral development process for new C systems. 
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In addition, a multi-disciplinary HSI advisory group, including both HSI professionals and 
operators, should be established to oversee the implementation of the HSI process. 

5.4.6 Human-System Interface Technologies 

Selected examples of technologies with near-term potential for C applications are described 
below. It is recommended that the AC2ISRC, in cooperation with AFRL and the C 2 Battlelab, 
investigate their utility and feasibility (along with others listed in Table 5-2) through prototyping 
and experimentation. 

• Automated speech recognition (ASR) technology is sufficiently mature to provide an intuitive 
interface for an operator. ASR would allow the operator to bypass the menu stmcture by means 
of natural language commands. The payoffs would be faster creation of the ATO with fewer 
errors. Faster spinup of augmentees would also be facilitated. 

• 3-D audio displays can drastically increase the intelligibility and effectiveness of multi-channel 
speech communications by spatially separating the apparent locations of speech signals presented 
to the operator over headphones. This makes it much easier to monitor multiple simultaneous 
talkers for critical messages and to focus attention on the critical talker in the presence of other 
competing speech messages. 3D audio displays also make it easier to determine the origin of 
speech messages and can improve situational awareness by providing intuitive information about 
the locations of objects relative to the listener. 3D audio is a mature technology that has been 
demonstrated in numerous flight tests and can be inexpensively implemented in new 
communications systems. 

• Untethered technology is being developed to allow battle commanders in Information 
Operations (IO) and C 2 operational environments mobile access to the information and people in 
their organization, even when they are not physically near their organization’s computers and 
databases. These technologies include, wearable computers, handheld and palmtop computers, 
and personal digital assistants. This line of technology development will facilitate battle 
commander interactions with wall-size and PC-based information displays and operational 
information databases, as well as facilitate communications with other command staff as they 
move from place to place within the organization. They will also allow the use of a wide variety 
of computer peripherals, such as speech generation technology and laser-based visual display 
controllers, without the cumbersome “umbilical cords” typically required to use these 
capabilities. Many warfighter organizations have identified the need for untethered, mobile 
technologies to support operational battle staffs as a significant factor in improving human 
decision making in wartime environments in the future. 

• Simple decision support systems that model the dynamics and uncertainty of the work 
environment using Bayesian inference techniques can be used to support contextual attention 
focusing and alerting of the warfighter. These systems would provide a “flag” (for example, an 
on-screen alert or an audible tone) when critical event thresholds are exceeded. Any alerting 
would be provided with the current work context taken into account to ensure that the alert is 
offered in the right format at the right time and that it does not increase the cognitive burden on 
the warfighter (see Appendix 5D for further detail). 

• Information visualization technologies are available to provide commanders and their staffs 
with displays to aid their comprehension of large volumes of data. Visualization tools shift 
information processing from lexical to spatial realms to enable rapid discovery, understanding, 
and presentation of data. AOC visualizations can be used in mission preparation and planning 
and in mission monitoring and assessment to portray the combined (air, space, and information) 
tasking. 
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• AOC recording capability could provide the AOC with “performance instrumentation” that is 
similar to that used to characterize and improve the performance of test aircraft. There is an 
emerging capability to record screen captures of the displays in the AOC at regular intervals. 
Tools must be developed that help commanders and operators better understand the processes 
employed in the AOC—so as to rapidly interpret anomalies and adjust, compensate, or change the 
processes as decision cycles increase in speed, complexity, and frequency. Academic researchers 
have developed process capture and reuse tools that can record audio and video of AOC 
activities. This multimedia data can then be indexed by screen capture shots taken from the data 
management systems that the team uses in the AOC (for example, large-screen tactical display or 
individual workstations). This could produce an easily navigated and reusable record of AOC 
activity during operations and exercises. Such a system could be used for briefings, de-briefings, 
crew changeover, post-mission effectiveness assessment, requirements definition, training, 
experimentation, and development of decision support tools. 

The field of cognitive systems engineering can also provide improvements to the methods and 
tools employed in developing C 2 decision support systems. Some of the more promising tools 
for C 2 applications include 

• Cognitive Work Analysis—a systems approach to identifying the constraints in a domain and 
using these constraints to guide the design process 

• Cognitive Task Analysis—a set of methods for describing the cognitive skills needed to perform 
a task 

• Decision-Centered Design—the use of cognitive task analysis to specify the difficult decisions 
and to use these as a basis for designing HSIs and decision support systems 
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Appendix 5A 

People and Organization Panel Charter 

The panel served as the technical arm to advise the Concept and System Definition Panel on 
human-system integration matters relevant to the 2005 system implementation. The panel also 
made recommendations to the Acquisition Panel on process improvements to ensure that human- 
system requirements are adequately addressed in procurement of future systems and in near-term 
upgrades to existing systems. The scope of effort addressed human-system integration issues for 

• Ground-forward 

• Ground-reachback 

• Airborne battle management C 2 

The panel assessed the allocation of functions to humans and automation in present Air Force C 2 
systems, and the process and criteria for making these decisions. The panel was also charged 
with identifying technologies and methods to optimize utilization of human and automated 
resources to maximize operating efficiency. 

With regard to the HSI, the panel was asked to consider information flow in both directions (C 
flow-down and feedback mechanisms). The study focused on presentation of relevant, critical, 
timely, accurate information to decision makers at all levels. This included dissemination and 
presentation of all mission-essential information and the establishment of necessary levels of 
situation awareness for commanders, analysts, planners, and aircrews. The panel was asked to 
recommend technological improvements in the areas of display media, control devices, 
automation, and decision-aiding to enable needed improvements in C 2 systems. The panel also 
assessed the readiness of key HSI technologies for near-term (2005) and long-term applications. 

The panel addressed personnel-related issues that impact C 2 system effectiveness, including 
selection, placement, training, and certification of C 2 specialists. This effort focused on problems 
associated with meeting the demands of high-tempo expeditionary deployments and their impact 
on the skills, qualifications, readiness, and retention of personnel. The panel made 
recommendations regarding concepts and/or processes to help ensure that the right person can be 
immediately deployed and employed in response to time-critical threats. Current Air Force 
organizational practices for C 2 were reviewed to determine whether they are conducive to 

• Rapidly getting qualified people (and equipment) to the crisis scene 

• Ensuring that training and readiness are effective and “as we fight” 

• Providing career ladders for the people—officers and enlisted 

• Applying contractor support where appropriate 

• Controlling personnel tempo 

The panel was also asked to identify and address human-system issues that impact integration of 
C 2 systems for joint or coalition operations. These findings took into account lessons learned 
from recent Air Force deployments and combat operations. 
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Appendix 5B 

People and Organization Panel Membership 

Mr. Jeffery B. Erickson, Chair 
Manager, Crew Systems 
The Boeing Company 

Col Lynn Carroll, USAF (Ret) 

Private Consultant 

Col Roger Carter, USAF (Ret) 

Program Manager, Advanced Information Systems 
Lockheed Martin Corporation 

Dr. Emily Howard 
Technical Fellow 
The Boeing Company 

Dr. Miriam E. John 

Vice President, California Division 

Sandia National Laboratories 

Maj Guy Jones, USAF (Ret) 

Senior Systems Analyst 
SenCom Corporation 

Dr. Gary Klein 

Chief Scientist and Chairman of the Board 
Klein Associates Inc. 

Prof. M. Elisabeth Pate-Cornell 

Department Chair, Management Science and Engineering 
Stanford University 

Col Bruce Queen, USAF (Ret) 

Director, Advanced Program Development Airborne Ground Surveillance & Battle Management Systems 
Northrop Grumman 

Dr. John Reising 

Technical Advisor, Crew System Integration Division 
AFRL/HE 

Lt Gen John B. Sams, Jr., USAF (Ret) 

Director, C17 Field Services 
The Boeing Company 

Col Hugh Smith, USAF (Ret) 

Manager, C 2 Operation 

TRW, Systems and Information Technology Group 
Advisor: Col Marc Lindsley 

Executive Officer: Maj Juan R. Berrios, ACC/INXX 
Technical Writer: Capt John M. Feland, USAFA/DFEM 
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Appendix 5C 

Available Command and Control (C 2 ) Training Opportunities 


Joint Forces Air Component Commander (JFACC) Course. The JFACC Course is the 
senior (joint-Service 0-7 level) professional military education course offered by the Air Force 
to prepare potential JFACCs for theater-level leadership responsibilities. Particular emphasis is 
placed on air power employment in theater-level operations using Theater Battle Management 
Core System (TBMCS) and other related equipment that will be available to future JFACCs. The 
JFACC course is 4.5 working days long—3 days at Maxwell Air Force Base, Alabama, and 
1.5 days at Hurlburt Field, Florida. 

Joint Air Operations Senior Staff Course (JSSC). The JSSC is a senior professional military 
training program. The course uses presentations, discussions, and physical equipment to provide 
an overview of the planning, coordination, integration, employment, and implementation of air 
operations strategy in joint operations. The program is designed to prepare colonels (or 0-6 
equivalents) and/or specifically selected lieutenant colonels (or 0-5 equivalents), selected by 
their respective Numbered Air Forces or equivalent organization, for senior leadership 
responsibilities in a Joint Aerospace Operations Center (JAOC). Presentations by a General 
Officer JFACC and three current directors from three JAOC locations lead off the program, 
followed by each Service’s operating considerations in a JAOC. Course length is 4.5 days. 

Command and Control Warrior Advanced Course (C 2 WAC). The purpose of the C 2 WAC is 
to prepare selected Air Force officers to perform duties that require advanced knowledge, skills, 
and ability in the C processes supporting the Joint Force Air Component Commander or 
Commander, Air Force Forces, decision making at the operational level of war. In keeping with 
the mission of the C 2 Training and Innovation Group, the C 2 WAC contributes to advancing the 
C 2 state of the art. Individuals entering this course should be field-grade officers, normally with 
a minimum of 1 year experience in an AOC, across the functions of A-l through A-6, including 
space, information operations, and mobility. 

Graduates of the C 2 WAC should be qualified to assume supervisory positions (cell/division 
chief) within an AOC. 

Joint Aerospace Command and Control Course (JAC 2 C). JAC 2 C focuses on C 2 of joint air 
operations in a theater battle at the operational level of war. This course covers basic doctrine, 
mission, and organization of the services; the Theater Air Ground System, command, control, 
and communications systems; intelligence support capabilities; tactical missions and major 
weapons systems used in joint operations; capabilities and limitations of C 2 warfare concepts and 
strategy; and computer tools used in current operations. The course includes lectures, seminars, 
hands-on computer activities, a C exercise prior to the final exam, and end-of-course Initial 
Qualification Training certification by functional area. 

Joint Aerospace Systems Administrator Course (JASAC). JASAC trains selected individuals 
in the fundamentals of UNIX, and Windows NT System Administration Terminal Control 
Protocol/Intemet Protocol networking and communications protocols, relational database 
TBMCS administration. The course focuses on individuals assigned to system administration 
duties within the JAOC, Numbered Air Forces, composite wings, or related joint organizations or 
facilities. Course length is 40 days. 
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Joint Aerospace Computer Applications Course (JACAC). JACAC trains selected 
individuals in the fundamentals of TBMCS operations, focusing on training individuals required 
to use TBMCS in a JAOC, other joint organizations, or closely related facilities. Individuals 
attending the course will normally be assigned duties at a JAOC, Battlefield Coordination 
Element, Control and Reporting Center, or other component facility. Course length is 4 days. 

Joint Combat Search and Rescue (JCSAR) Coordinator Course. JCSAR Coordinator 
Course provides individuals with needed information for functioning in a Joint Search and 
Rescue Center (JSRC) and to be aware of the dynamics involved in one. The course exposes 
students to the procedures and requirements for establishing and running a JSRC or a 
component-level Rescue Coordination Center. A cursory overview of the Personnel Recovery 
program will be provided. This and many other aspects will be used to recover personnel in 
distress in an Area of Operations. Course length is 4 days. 
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Appendix 5D 

Risk-Based Decision Support Systems for Commanders 
Elisabeth Pate-Cornell 


Quantification of uncertainties, for example, probabilities of target destruction in combat 
assessment, is currently done informally based on experience, at least by some commanders. 

This process includes sequential updating of the probability of success, based on pilot reports 
and sensor data. It also involves a threshold of probability above which the commander is 
confident enough that a given target was destroyed to proceed with further operations. 
Automation of this individual thinking process, through small, simple, computerized systems, is 
feasible and would be helpful in managing the fog of war. Applications include combat 
assessment and choice of sensor(s) for a given task. 

Based on Bayesian logic and probabilistic risk estimates, these combat decision support systems 
could automatically provide a “flag” when specified thresholds of probability are exceeded. 

These systems have to stand alone and be easy to use. They could be implemented, for instance, 
in small hand-held computers that could be docked into larger systems when useful statistics can 
be found elsewhere. Key input will include the probability of an event before reports and 
signals, the probabilities of errors (false positives and false negatives) in intelligence reports and 
sensor data, and the thresholds above which the probability of the event of interest is high 
enough that there is no need for additional information. Some of these data (for example, the 
performance of sensors) can be gathered and processed centrally. But for the most part, these 
decision support systems are to be fed and updated at the local Air Operations Center level, 
based on on-site information, for example, the prior probability of the event of interest given the 
local conditions. The confidence level (“flag”) required before further action must be 
determined by the commander. 

The results of these models must be transparent, comprehensible, and checkable against intuition 
to verify that all relevant factors that the human mind would instinctively (and often implicitly) 
account for are included in the computation. The benefits of these support systems could include 
faster results, fewer people involved in intelligence processing, enhanced accuracy, and 
provision of knowledge rather than data. 

Probability figures cited by an experienced commander as an illustration of an informal way of 
doing this reasoning seem to be conservative in the probabilities rather than in the “flag” used for 
decision making. The combination of probabilities that appear conservative and of a threshold 
that seems low permits the commander to determine, in the end, the degree of risk to take. The 
problem is that conservatism in the probabilistic estimates makes it difficult to maintain 
consistency when combining information from different sources. It is more logical when 
computing a single risk figure (to be compared to a “flag”) to use mean probabilities (for 
example, mean future frequencies), and to put the desired conservatism in the threshold that 
triggers the “flag” (that is, a higher threshold). This approach, without significantly modifying 
the reasoning, would allow consistent use of the best available information and accurate 
combination of probabilities while preserving the desired level of conservatism in the decision. 
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Chapter 6 

Report of the Acquisition and Program Management Panel 


6.1 Introduction 

The Acquisition Panel examined the acquisition process to acquire and evolve command and 
control (C ) systems to support the decision-makers in air operations. Our particular focus was 
on theater C 2 systems—such as the Theater Battle Management Core System (TBMCS)— 
acquisition and evolution. We took the following approach in developing our findings and 
recommendations: 

1. We developed a list of desired attributes of an acquisition process for C 2 systems. 

2. We described the current Air Force acquisition process for C 2 systems (and everything else) by 
doing a case study of the TBMCS acquisition as a normative example. 

3. We searched for examples of other acquisition processes that might better satisfy the desired 
attributes for C 2 systems. 

4. We formulated our findings and recommendations for modifying the current Air Force 
acquisition process for C 2 systems—especially for the Theater Aerospace C 2 System (TACCS)— 
the focus of this study. 

We determined that an evolutionary integration process similar to the one used by the Defense 
Information Systems Agency (DISA) in evolving the Global Command and Control System 
(GCCS) is more appropriate than what we have used in the past for acquiring and evolving C 2 
systems. This process also involves evolutionary development, but in a much more timely, 
diffuse, and distributed way than it has been done in the past in the Air Force. In addition to 
integration and development process changes, we agree with the other panels that major 
improvements are needed in institutional focus on C 2 in the Air Force (it should be a core 
competency), in advocacy for a coherent Air Force C 2 program (we need an Air Force Council 
Representative addressing C 2 and its supporting structures alone), in funding for the proper 
infrastructure to do integration of new capabilities into C 2 systems (a program element [PE] 
funded and advocated by the Air Force Materiel Command [AFMC]), and major restructuring 
and consolidation of program elements and Air Staff panels. 

6.2 Approach and Visits 

The first meeting of the summer study was conducted on 7 March at the U.S. Air Force 
Academy. This was a panel-chair kick-off meeting to review the Terms of Reference. On 
8 March, the Acquisition Panel Chairman met with the General Manager of Lockheed Martin 
Colorado Springs, Mr. Pete Rogers, to discuss the TBMCS program and general acquisition 
approaches for such programs. 

The next meeting was the Air Force C 2 kick-off meeting at Hurlburt Field, FL on 20-21 March. 
The panel was hosted by the Air Force C 2 Innovation and Training Group and received study 
guidance from the Air Force C 2 Study Chairman, Dr. Worch. The panel also received briefings 
from Maj Gen Perryman (Commander, the Aerospace Command and Control, Intelligence, 
Surveillance, and Reconnaissance Center [AC2ISRC]), Lt Gen Kenne (Commander, Electronic 
Systems Center [ESC]) and BGen Obering (Assistant Secretary of the Air Force, Information 
Dominance [SAF/AQI]). 
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The Acquisition Panel then visited ESC 3-5 April for an information-gathering meeting. 

Lt Gen Kenne hosted the panel and her staff provided briefings on Global Air Traffic 
Management System, TBMCS, Spiral Development, the Joint Surveillance Target Attack System 
(JointSTARS), Integrated Space Command and Control (ISC 2 ) program, Joint Expeditionary 
Force Experiment (JEFX), Joint Battlespace InfoSphere (JBI) and a number of other programs. 

The entire Air Force C 2 study then convened at Langley Air Force Base (AFB) on 10-11 April 
and was hosted by AC2ISRC. Maj Gen Perryman and his staff provided various briefings on 
Combat Air Force (CAF) C 2 and visitors also took a tour of the Air Combat Command Network 
Operations Security Center. 

The next information gathering meeting of the acquisition panel was on 18-20 April in 
Washington DC. Panel members met with Ms. Darleen Druyun (Assistant Secretary of the Air 
Force, Acquisition [SAF/AQ]), BGen Gary Salisbury (DISA/D-6) and Mr. John Gilligan, 

(DOE/Chief Information Officer [CIO]), who was previously the Program Executive Officer 
(PEO) of Battle Management, and under whose aegis the integration of the Contingency Theater 
Automated Planning System (CTAPS), the Wing Command and Control System (WCCS), and 
the Combat Intelligence System (CIS) into the current TBMCS program was initiated. 

The entire Air Force Scientific Advisory Board then met at Nellis AFB, NV for the Spring Board 
Meeting on 24-27 April. The Air Force C 2 study received additional briefings from ESC. The 
panel also received briefings on RED FLAG and toured the RED FLAG facilities. 

On 28 April, panel members traveled to Colorado Springs to visit Lockheed Martin concerning 
TBMCS specifically. The panel met with Mr. Steve McCulloch and Mr. Reese Delorey, the 
initial and current Lockheed Martin TBMCS program managers. 

Maj Gen Nelson audited major portions of an Armed Forces Communications Electronics 
Association-sponsored GCCS course in Washington DC on 8-12 May to gain further insight into 
the current GCCS program. 

Panel members traveled to Washington DC on 16-18 May. The panel met with the following 
individuals to get their opinions on the GCCS integration process as well as their specific 
recommendations on the acquisition process for TACCS: 

• DISA/D-6, BGen Salisbury 

• Space and Naval Warfare System Command (SPAWAR), Dr. Frank Perry 

• SAF/AQI, BGen Obering 

• Deputy Chief of Staff, Air and Space Operations (AF/SC), BGen Bell 

• AF/XOC, Maj Gen Hess 

• AF/XOJ, Maj Gen Baker 

• AF/XOR, Mr. Disbrow 

• AF/XPP, BGen McNabb 

The Chairman participated in a Panel Chairs’ meeting at Woburn, MA on 13-15 June. 

The panel returned to Washington DC on 26-27 Jun to meet once again with DISA—Ms. Dawn 
Hartley; Ballistic Missile Defense Organization—Lt Gen Kadish; SPAWAR—Dr. Frank Perry; 
and the Advance Information Technology Service Joint Program Office (JPO)—Mr. Jim Moody. 
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All panel members participated in the report development phase at San Jose, CA 10-21 July. 

The Chairman went to Wright-Patterson AFB on 7 August to collect information at AFMC 
Headquarters (HQ). He met with the AFMC commander, Gen Lyles, and Lt Gen Kenne and 
Lt Gen Raggio, commanders of ESC and Aeronautics Systems Center. 

6.3 Desired Attributes of an Acquisition Process for C 2 Systems 

The process defined in the Department of Defense Directive (DoDD) 5000.1 for the 
acquisition 24 of major systems is still, even in the current revision, slanted toward the big dollar 
hardware systems such as F-22—and that is probably as it should be. But there is a major 
difference between these big hardware systems and C 2 systems—the basic technology to support 
system implementation is evolving at a much higher rate for the latter. And, in addition, the 
ability to clearly define the requirements for the system in the latter case is much more difficult. 

It is really true that the operator will know whether or not he likes a capability of a largely 
software-based C 2 system after he has tried it, while he knows even before a prototype is built 
what the basic capability improvements in a new fighter should be. Because of these differences, 
the assumption that one acquisition and sustainment process should serve all systems is an 
erroneous one. The C 2 process should allow much more operator modification, either through 
improvements made by the operators themselves while operating real systems, or through 
integration of new capabilities demonstrated in laboratories or such activities as Advanced 
Concept Technology Demonstrations (ACTDs) and JEFX. Hence, we postulate a more 
appropriate acquisition approach for C 2 systems in general as one that has: 

• The interest and attention of senior Air Force leadership 

• A planning, programming, and budgeting process that fosters cohesion of the components (for 
example, for the TACCS: JointSTARS, air operations center [AOC], Theater Air Control System, 
etc.) and continuity of development for appropriate components 

• A development and evolution/integration process that: 

- Allows for the recognition of need for new capability during system operation 

- Allows for the rapid integration of already developed and tested hardware and software to 
satisfy emerging new capability requirements 

- Allows for the rapid development, testing, and integration of new capabilities when and 
where needed 

• Fosters continuous communication among the participants in the acquisition—especially 
including the actual users (as opposed to only with surrogates for them) 

• An organizational structure and appropriate resources to execute the PPBS and 
development/evolution processes 

23 DoDD 5000.1 still describes a process which may be summarized as: collect and clearly state the system’s 
requirements, develop and test a system implementation that satisfies those requirements, do an independent 
operational test to insure that the operational requirements are met, field the system and sustain it. It is implied 
that if a significant increase in capability is required, another acquisition cycle is needed. 

24 Acquisition is defined as development and procurement. For C 2 systems as well as for major hardware systems, 
there is a subsequent phase called sustainment—that includes evolution of the system (for example, block changes 
for airplanes), but for C 2 systems, evolution is a much more significant activity than for major hardware systems. 

25 “continuity of development” means avoiding the “big bang approach” discussed in footnote 1 above—and instead 
instituting a continuous development and integration process—much like we define sustainment after a major 
system’s initial development and fielding. 
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• Clear definition of authority and responsibility (for example, who owns the concept of operations 
[CONOPS], who speaks for the (joint) users in defining the requirements, who directs the 
contractors involved, who makes decisions on operational suitability...) 

• Development and integration entities primarily motivated by the success of their efforts 

6.4 The Current Air Force Acquisition Process for C 2 Systems 
6.4.1 Acquisition Management 

Based on the recommendations of the Packard Commission to improve the Department of 
Defense’s (DoD’s) organizational arrangements and acquisition management procedures, the 
Goldwater-Nichols Reorganization Act was made a public law in 1986. The recommendations 
centered on increasing efficiency and effectiveness, reducing costs, and decreasing acquisition 
cycle times. 

The Air Force implemented the Act, similar to the other Services, by the creation of a Service 
Acquisition Executive (SAE), PEOs, and program managers (PMs) to make up the Acquisition 
Management System. The statute provided a new Under Secretary of Defense (Acquisition) to 
provide overall DoD policy for procurement, research, and development. Most noteworthy was 
the appointment of PEOs to be responsible for a reasonable and defined number of acquisition 
programs. The PEOs would be responsible directly to the SAE. 

In the reorganization, the former Product Center and Air Logistics Center Commanders were 
made Designated Acquisition Commanders (DACs) and were to provide support to the PEOs 
and PMs. The DACs would be decision authorities for assigned programs. DoDD 5000.2-R 
requires assignment of program responsibilities to PEOs for all ACAT I, ACAT IA, sensitive 
classified programs, or any other program determined by the SAE to require dedicated executive 
management. DoDD 5000.2-R further states that to transition from a PEO to a commander of a 
systems or logistics command, a program shall have passed Initial Operating Capability (IOC), 
have achieved full-rate production, and be logistically supportable as planned. The purpose of 
these changes was to provide stability to an organizational structure and make arrangements to 
place highly qualified people in charge of programs with the appropriate authority and 
responsibility. Decentralized execution and reduced bureaucratic layering would be the result. 

The Air Force complied with DoD’s guidance and Congressional legislation by removing 
layered procurement decisions and unaccountable acquisition officials from the Air Force 
structure. Major programmatic decision authority was removed from AFMC. Although the PMs 
now have a higher level of accountability, these streamlining efforts developed a process of 
program execution that is complex, interactive, and not autonomous. The basic question is, 
“How have these acquisition reforms increased effectiveness and efficiency of the Acquisition 
Management System where actual program execution takes place?” This question is more 
difficult because there are no metrics to measure the performance of the reorganization. 

From the PEO and PM perspective, there has been a mixed reaction with regard to the results of 
the reorganization. Results are highly dependent on the personalities and attitudes of the 
participants. There is consensus that the PM’s decision-making authority has been enhanced. 
With regard to acquisition management of C 2 systems, the assignment of portfolios to two PEOs 
and one DAC contributes to fragmentation of the TACCS. Previously, some C 2 systems were 
also assigned to Air Logistics Center Commander’s (DACs) portfolios. These programs make 
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up the overall TACCS, but are not assigned to a specific portfolio for management. This leads to 
inconsistency and instability of the overall TACCS program. Further, the assignments of the 
PEOs and PMs to these programs have been shorter than the reorganization had planned. The 
Air Force has not controlled the reassignments to milestone achievement such as IOC, full rate 
production, and logistically supported systems. 

Another goal of the PEO reorganization was to force system integration across individual 
portfolios. Since the original portfolio assignment, the importance and visibility of the TACCS 
program has increased. This suggests a reassessment be made to include all those programs 
within TACCS to enhance mission area integration. There are currently insufficient resources 
within each program element that makes up the TACCS program for overall integration. 
Therefore, the PEO/DAC portfolios currently miss the opportunity for commonality, 
interoperability, and standardization across the C 2 mission area. 

6.4.1.1 Recommendations 

• Establish metrics to measure the effectiveness of the PEO management system 

• Stabilize assignments of PEO/PMs to match milestone achievements 

• Reassess portfolio assignment of programs to a single PEO/DAC to enhance commonality, 
interoperability, and standardization 

6.4.2 The Current Air Force Acquisition Process for C 2 Systems: A Case Study of TBMCS 
(abbreviated—full text in Volume 2, Appendix 6C) 

The TBMCS program is the current Air Force flagship program for automating and integrating 
the planning and execution of the theater air war. Its five core functions can be defined as: 

• Intelligence collection and evaluation 

• Planning 

• Generating and distributing the Air Tasking Order (ATO) 

• Unit level scheduling of missions 

• Monitoring execution of the ATO 

TBMCS is intended to link these intelligence, planning, and operations functions through the 
integration of several legacy systems (or their equivalent functional capabilities), the most 
important of which are CIS, CTAPS, and WCCS. In addition, TBMCS migrates these key 
theater air warfare applications to the Defense Information Infrastructure Common Operating 
Environment (DII COE) platform. The complexity of this integration and migration was 
underestimated in the mid-1990s when the program was initiated (as have been most, if not all, 
similar integrations). In the recent words of the then-PEO: “It’s the most difficult program I 
have ever encountered.” 

TBMCS has experienced a troubled and controversial history since its formal launch in late 
1995, when Loral (now Lockheed Martin Mission Systems [LMMS] of Colorado Springs) won a 
six-year competitive cost plus award fee contract valued around $180 million. The program has 
suffered from significant schedule slippage, some cost growth, and major performance short 
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falls. The original contract envisioned the fielding of three progressively more capable 
software releases. Instead, as of June 2000, the program still had not been able to successfully 
complete and field Version 1.0. In addition, the current Version 1.01 represents a significant 
down-scoping in the capabilities originally envisioned for the first release. As a result, TBMCS 
is now widely considered to have been a seriously flawed program with regard to its 
development process, at least in the early phases. The program now, however, generally seems 
to be on track. A detailed plan for the fielding and future upgrading of the system has been 
developed. 27 Nonetheless, its many problems in its early phases make it worth examining 
carefully for “lessons learned” for future Air Force approaches to C 2 systems acquisition. The 
following is a list of lessons learned gleaned from extensive interviews with the key Air Force 
PEO, PMs, and LMMS senior managers, as well as from examination of numerous program 
office documents and briefings. 28 

Lack of sufficiently detailed CONOPS, system architecture, and operational requirements. 

TBMCS was launched with a strong visionary high-level CONOPS and system architecture. 
However, these lacked the detail necessary to provide appropriate guidance to the Air Force and 
contractor PMs for development of the system. No formal Operational Requirements Document 
was ever produced. 29 The problem was compounded by the lack of consensus among the user 
communities over CONOPS and operational requirements, and by continual change and 
evolution. The constant refrain of the contractor remained: “Will the real user please stand up?” 

Lack of consistent, strong advocacy leadership in the highest levels of the Air Force, and at 
the System Program Office (SPO) and contractor levels. Initially TBMCS had a few strong 
advocates in the highest levels of the Air Force. At one key point during the development phase, 
an Air Force Major, far down in the SPO hierarchy, acted as the de facto PM for nearly a year. 
The program lacked clear lines of authority and strong leadership both on the government side 
and the contractor side. 

Inappropriate application of current acquisition reform (AR) doctrines of transferring 
greater system definition responsibility to the contractor. Partly by default, and partly 
because of DoD AR doctrine, the contractor was granted significant control over the 
development of the system operational architecture, configuration, and even CONOPS. The 
contractor senior management lacked the operational knowledge, technical skills, and initiative 
to meet this challenge effectively without greater guidance from the Air Force. Clear guidance 
was not forthcoming. 

Use of a “big bang” development approach instead of a spiral development style of 
approach, which delayed fielding, and resulted in operator pressure to divert resources to 
fixing legacy systems. The TBMCS contract called for the development and fielding of three 
major software releases over a six-year period. The user community lobbied hard for a much 


26 The original contract value to the prime contractor was $35 million (excluding fee, zero base fee), with options 
that were eventually exercised amounting to $109 million, resulting in a total of $144 million. Award fees and 
miscellaneous changes raised this to $179 million. A category labeled “evolutionary Requirements (TTDs)” 
added an additional $161 million, for a total contract value in mid 2000 of $327 million. Mr. Stephen Kent, ESC 
provided this information. 

27 TBMCS passed its Field Demonstration Test in June 2000. An MOT&E was accomplished in late July. 

28 An extensive and detailed case history of TBMCS is included in Appendix 6C of this volume. 

29 CTAPS and WCCS did have formal System Operational Requirements Documents. 
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quicker fielding of initial capabilities. This led to the decision to divert significant resources to 
fixing existing fielded systems (CTAPS, CIS, WCCS). This effort proved far more difficult than 
anticipated, leading to significant delays in the program, because the fielded legacy systems were 
seriously flawed. In theory, a spiral development approach could have led to a much earlier 
fielding of initial capabilities, thus reducing the pressures to divert resources to fixing legacy 
systems. 

Insufficient “jointness” in the original program planning. Failure to include sufficient joint 
vision in initial program planning contributed to the unanticipated need to rehost CTAPS to 
Hewlett Packard and SUN servers for Navy shipboard operations. This was identified as a major 
unplanned diversion of resources. In general, Navy requirements and needs were not sufficiently 
recognized in the early phases of the program. 

Underestimation by both the government and contractor of the technical difficulty of 
integrating legacy systems. Multiple contractors had developed the legacy software modules, 
usually in conjunction with a specific lab and a specific user command. Thus the pieces that 
would make up TBMCS had no uniformity in architecture, computer language, etc. Little formal 
documentation existed, resulting in difficulties in transferring the necessary legacy information 
to LMMS. This problem was exacerbated by third party “associate” contractors that had no 
formal contractual relationship with LMMS. Third, some particularly troublesome modules, 
such as Force Level Execution (FLEX), were developed by labs as tech demos, and were not 
appropriate for fielding. In the case of FLEX, neither the SPO nor LMMS had direct control 
over development. Finally, virtually all the legacy modules were more immature technically 
than originally anticipated. 

Inadequate process for controlling and screening requirements/capabilities development 
and additions. The user community continued to develop new modules and capabilities that 
were folded into the program. No process existed to assess, prioritize, and filter these, leading to 
much added integration work. Little discipline was exercised over requirements growth and 
change, since no clear baseline configuration was ever established early in the program. 

Lack of an appropriate strategy for testing and fielding the system. The program did not 
develop a consensus on a unified testing concept and approach, nor on test metrics forjudging 
success. A lack of a unified and detailed CONOPS resulted in the lack of a standard use pattern 
by users. Different testers, with different use patterns, and using different test metrics, conducted 
the various operational and fielding tests, producing widely varying results. This was a major 
stumbling block to fielding. 

6.5 Other Acquisition Approaches for C 2 Systems 

In the time allotted for collecting data, the panel was not able to do an exhaustive study of 
Government and commercial approaches to acquiring C 2 or C 2 -like systems; however, the 
following four examples are worthy of note for their acquisition process and structure: 

• DISA acquisition of GCCS 

• Navy development of Global Command and Control System-Maritime (GCCS-M), 

• Air Force ISC 2 Program 
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• Department of Defense Intelligence Information System (DODIIS) managed by the Defense 
Intelligence Agency (DIA) and the Air Force. 

6.5.1 GCCS 

6.5.1.1 The GCCS 

In the mid-1990s DISA instituted a process for evolving GCCS. It replaced the mainframe- 
based Worldwide Military Command and Control System with a more capable modem system. 
The process follows a similar process put in place by SPAWAR in the late-1980s when that 
command tried to come to grips with multiple versions of several stovepiped C 2 systems 
operating in the Fleet. GCCS is the cornerstone of the command, control, communications, 
computers, and intelligence (C 4 I) for the warrior and addresses the mission need statement for 
GCCS, 8 June 1995. GCCS, as a warfighter-oriented system, provides improved information 
processing support in the areas of planning, mobility, and sustainment to combatant 
commanders, the Services, and Defense agencies. GCCS consists of all necessary hardware, 
software, procedures, standards, and interfaces for connectivity worldwide at all levels of 
command; and supports and integrates a wide assortment of mission critical, inter-Service, 
Service, and site-unique applications, databases and office automation tools. It provides an open 
system infrastructure that allows a diverse group of systems and commercial-off-the-shelf 
(COTS) software packages to operate at any GCCS location with a consistent look and feel. 
GCCS users can readily access web-enabled applications and databases. The functional groups 
within GCCS are situational awareness, force planning, and office automation and messaging. 
GCCS has been characterized as a non-near-real-time system, but recent application integrations 
have brought it closer to dealing with the near-real-time environment. 

6.5.1.2 DISA and GCCS Evolution 

DISA’s process to evolve GCCS is closer to a sustainment than a development process. It 
recognizes the rapid evolution of software, computer hardware, and communications 
technologies and seeks to save time and money by integrating capabilities (applications) into the 
GCCS after those applications have been developed in prototype form and found operationally 
useful through ACTDs, exercises, etc. This approach reverses, in a sense, the classical 
acquisition approach, which does operational testing after the major and costly work of 
requirements collection, development, and integration have been accomplished. (There will 
often have been a prototype developed and tested before the classical acquisition process is even 
started). The process depends on the applications having been developed, frequently over a few- 
year period, to be compliant with a supporting structure, or platform—in this case the DII COE. 
While an application may have taken years to develop and operationally test, the process of 
integration and fielding typically is done within two to three months. 

The Joint Information Engineering Organization (JIEO) manages the evolution of the GCCS and 
the evolution of the COE. The DISA D6 is normally the Commander of this organization. There 
is no grand design or master set of requirements against which the system is evolved, rather— 
there is a new requirement identification and prioritizing process accomplished annually. The 
commanders in chiefs (CINCs), Services, and Agencies identify and validate requirements for 
new capabilities to be integrated into GCCS. Applications addressing those requirements are 
typically validated operationally in exercises, ACTDs, and the like—and have been developed in 
compliance with the COE (typically at level 7). A series of functional working groups overseen 
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2 

by the Joint Staff J3 (recall, the GCCS is the CINCs’ C system) ranks those requirements, as the 
JIEO has essentially a level-funded budget each year and hence integration of all requirements 
cannot be accommodated. 

Using primarily a set of facilities in the DC area (a principal one being the Operational Support 
Facility), the JIEO and its contractors integrate the COE-compliant applications which have been 
approved into the GCCS and distribute new software to well over a hundred sites worldwide. 

This integration typically takes a few months for each application, even though the development 
and operational test of an application may have taken a few years. Applications are fielded 
continually, usually a few per month. The integration cycle is shown graphically in Appendix 
6D of this volume, and a recent schedule for applications fielding is in Appendix 6E. A list of all 
applications and their descriptions is at Appendix 6F. To execute this GCCS integration process, 
the JIEO has a budget of approximately $60+ million annually (PE 0303150K), mostly 
operations and maintenance (O&M) (some procurement), and mostly for contractors and 
facilities. There are also approximately 200 government personnel (mostly Civil Service) funded 
in other lines. For DII COE maintenance and evolution, DISA D6 uses approximately $25 
million annually, mostly for contractors and facilities, along with 40-50 government personnel 
(mostly Civil Service). Supporting the whole effort are a number of other facilities and 
organizations, such as the JPO (the Defense Advanced Research Projects Agency/DISA), which 
facilitates development and ACTD transition (approximately $25 million annually, including 
approximately 50 contractors, facilities, and about 20 government personnel), and the Joint 
Development and Evaluation Facility (a mini CINC HQ), assigned to DISA D8. There are other 
facilities and participants as well. Procurement and sustainment funding is the responsibility of 
the individual CINCs. 

6.5.2 SPAWAR and GCCS-M Evolution 

It is important to understand the Navy structure for defining requirements and developing and 
acquiring C 2 systems. C 2 requirements stem from fleet originated needs and are forwarded to the 
Chief of Naval Operations, specifically the Director of Space, Information Warfare, Command, 
and Control, N-6. 30 These requirements are refined and become part of a balanced budget 
process, meaning that C 2 items are balanced against all other needs, including ships, aircraft or 
personnel, at the Office of the Chief of Naval Operations level. The requirements and the 
necessary resources are then passed to one of the Navy System Commands or a PEO for 
development and acquisition. Figure 6-1 graphically captures the essence of this centralized 
process. 

The SPAWAR philosophy that has been used in acquiring and evolving GCCS-M is essentially 
the same as DISA’s process in evolving GCCS. This is not surprising given that RADM John 
Gauss, who now commands SPAWAR, and Dr. Frank Perry, his Technical Director, created the 
DISA D-6 structure during their tenure in DISA and had defined the SPAWAR process several 
years earlier. RADM Gauss was the SPAWAR Program Manager for what was then the Joint 
Operational Tactical System (JOTS) system. 31 As program manager, Gauss’s job was to bring 
JOTS under configuration control. He additionally realized that the many other stovepiped C 2 


30 Although some other Navy organizations have some involvement in C 4 , N-6 is clearly the central point of focus 
and spokesperson within the Navy for these matters. 

31 JOTS, variously the Joint Operational Tactical System or the Jerry O. Tuttle System, an early fleet inspired and 
deployed C 2 system which was well accepted but not under adequate configuration control. 
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systems, each with distinct software, operating systems, and databases were costly to maintain 
and needed to be brought into a common system or retired. The process chosen was the 
beginning of the process now used for both GCCS and GCCS-M. In its very essence, that 
process is to define a COE and specify standards and a process for implementing applications 
that will run on this COE. This process is described in Appendix 6G of this volume. 
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Figure 6-1. Major Decision-Making Support Processes in the Department of the Navy 


Candidate applications for use on GCCS-M are frequently first demonstrated in naval exercises 
and then integrated into GCCS-M. SPAWAR has formed a strategic alliance with the Naval 
Warfare Development Command and has participated with them in Fleet Battle Experiments. 
Important thrusts like Time Critical Strike have found a pre-determined pathway through 
experimentation and prototyping to production deployment. Most of the development and 
integration work is done at two major SPAWAR field activities in Charleston and San Diego. 
The annual funding, including contractor support, is approximately $30 million RDT&E, 

$30 million O&M, and $120 million procurement. In addition, there are approximately 
34 people in the HQ office for GCCS-M who are funded out of the HQ personnel resources. 

The GCCS-M program is at the ACAT II level. Fleet Commanders supplement the procurement 
funds by buying additional PC’s and LAN backbones that SPAWAR installs. Under the 
Information Technology-21 (IT-21) 32 concept, SPAWAR is able to upgrade four Battle Groups 
or Amphibious Ready Groups each year with current versions of GCCS-M and concomitant 
hardware and supporting software. Grouping the fleet by Battle Groups, Amphibious Ready 
Groups, or Fleet Flagships yields 29 major afloat IT-21 installations including GCCS-M. 33 


32 IT-21 is a Navy plan to up-date the information technology capability of each deploying Battle Group so that each 
ship in the Battle Group is raised to a common level of hardware and software for information technology. 

33 The 29 consist of 12 Carrier Battle Groups, 12 Amphibious Ready Groups and five flagships supporting 
numbered fleet commanders. One of the five flagships is in reality a command center in Bahrain supporting the 
Naval Component Commander in the Central Command. 
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Commonality between GCCS and GCCS-M is estimated at 95 percent. GCCS-M constitutes 
Vi - % of each Battle Group’s C 2 capability, not considering the combat direction capability of 
the ship. 

6.5.3 Air Force Space Command (AFSPACECOM) and the ISC 2 Effort 

The ISC 2 Program is being managed through a PEO, using ESC resources in the Strategic and 
Nuclear Deterrence C 2 SPO. Most of its few hundred people physically located in Colorado 
Springs, collocated with the Operating Command (AFSPACECOM); the remainder are at ESC. 
The SPO is charged with awarding a contract mid-2000 for a long-term (15 year) alliance with a 
single contractor. The contractor will assume Total System Performance Responsibility (TSPR) 
to evolve from the current North American Air Defense Command (NORAD) U.S. Space 
Command (USSPACECOM) Warfighting Support System (N/UWSS) to a target operational and 
system architecture that is being developed as part of the contractor downselect. The plan is that 
the effort will be level-funded, at the total level of the currently existing systems, which provide 
the as-is capability (approximately $100 million total annually in various appropriations, 
RDT&E, procurement, and O&M). DII COE compliance is required. 

ISC 2 efforts. ISC 2 work will be concentrated in the following areas: 

• Sustainment of new and existing ISC 2 systems 

• Migration of existing ISC 2 systems to a common integrated architecture 

• New C 2 capability development and fielding in a common integrated ISC 2 architecture 

• Achieving interoperability and collaboration among ISC 2 operation centers 

• Enabling and performing external integration of the ISC 2 systems with Air Force, DoD, and other 
interfacing systems with emphasis on operation center/node interoperability 

• Organizational level maintenance of ISC 2 systems 

ISC 2 contract. The ISC 2 contract will address USSPACECOM, NORAD and their component’s 
ballistic missile/C 2 and related requirements (for example, N/UWSS). This includes both 
existing requirements, as well as those needs, like Information Operations, Shared Early 
Warning and Space Battle Management and Control emerging during the contract period of 
performance. The contract scope will also include system development, modification, 
integration, and support for other organizations with related missions (for example, U.S. 

Strategic Command’s [USSTRATCOM’s] Mobile Consolidated Command Center needs). The 
ISC 2 contract will evolve the as-is system to eliminate or mitigate the current system’s 
shortcomings. 34 

A major objective is to create a long-term Govemment/Contractor partnership with the 
contractor realizing a sense of program ownership and allow the Government to reduce the size 
of the SPO. The contractor will manage and facilitate integration with systems outside the ISC 2 
contract and establish a comprehensive and integrated training program for the lifecycle of all 
systems within the ISC contract. They will provide SPO level integration, systems engineering, 
and test support across SPO programs. The minimum functions the ISC 2 contractor must cover 
include: 

• Requirements impact analysis, coordination, and allocation 


34 N/UWSS Capstone Requirements Document, dated 21 February 1999. 
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• Integrated cross-SPO architecture activities 

• Configuration management activities 

• System-of-systems level enterprise information system 

• Integrated scheduling 

• Integration issue identification, tracking, and resolution 

• Logistics planning for architecture evolution 

The ISC 2 approach is different in some key ways from the DISA GCCS and SPAWAR GCCS-M 
activities. The main differences: 

• The Air Force seeks to assign TSPR to the contractor on ISC 2 , while the GCCS and GCCS-M 
efforts explicitly reserve it to the Government 

• The Air Force seeks to reduce people resources required to manage a C 2 program by assigning 
most of the program management responsibilities to the contractor 

• There is a target operational and system architecture specified at the outset of the 

Air Force/contractor alliance which requires an evolution plan to reach the goal from the as-is 
state. This feature is not in the GCCS nor GCCS-M programs 

• ISC 2 is built on the DII COE as a main foundation—but not explicitly on GCCS. It must 
interoperate with GCCS, TBMCS, and USSTRATCOM 

The other major difference is that the ISC approach is yet to be evaluated, while the GCCS 
approach has been in operation for at least a few years. There are at least three similarities 
between the ISC 2 and GCCS/GCCS-M approach: 

• Both assume a level of effort on a relatively long-term program to evolve the C 2 capability—this 
is a new approach for the Air Force acquisition structure 

• Both evolve through integration of developed and operationally proven applications 

• Both depend on a cooperative enterprise among user, acquirer, tester, and contractor 

6.5.4 Department of Defense Intelligence Information System 

The DODIIS architecture is managed by DIA and incorporates intelligence collection, 
processing, exploitation, and dissemination mission applications all existing in a common 
computing infrastructure. Individual applications are produced and maintained by the individual 
Services and various Combat Support Agencies (DIA, National Imagery and Mapping Agency 
[NIMA], and National Security Agency [NSA]). The DODIIS integration and testing process is 
very similar to the GCCS approach and has been in place for over five years. In addition to 
leading the technical development for the DODIIS infrastructure transition to DII COE, Deputy 
Chief of Staff, Air and Space Operations, Intelligence, Surveillance, and Reconnaissance 
(AF/XOI) manages the life-cycle development of several intelligence mission applications (via 
ESC/IC and Air Force Research Laboratory (AFRL), Information Directorate (AFRL/IF) 
procurements) and is also the Executive Agent for DODIIS integration and test. The Air Force 
coordinates all responsible test agency involvement, including the Joint Interoperability Test 
Center for interoperability testing, AFRL Joint Integration and Test Facility (JITF) for 
integration testing, DIA for security certification, and the appropriate agency or Service training 
certification. The JITF at AFRL/IF conducts integration testing to ensure each release of a 
DODIIS product meets the infrastructure requirements. Results of DODIIS testing/certification 
activities are reported to the DODIIS Management Board (DMB) via attachments to an 
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Acquisition Decision Memorandum. The DMB approves/disapproves deployment of individual 
products based on this input. 

DODIIS implementation. All AF/XOI-managed DODIIS software programs utilize a spiral 
development process; examples include the Communications Support Processor (CSP), 
Information Support Server Environment (ISSE) Guard and PROJECT BROADSWORD. Each 
of these products have been successfully exported from the intelligence community to the Air 
Force C 2 community after incorporating C 2 -specific requirements via “spirals.” The GCCS-like 
DODIIS integration and testing process lends itself particularly well to spiral development due to 
parallel conduct of various test and certification activities and the less than 60-day integration 
certification timeline. The GCCS and DODIIS integration and test model focus on relaying 
specific infrastructure requirements to the developing program office early in the development 
process and assessing an individual product’s evolving compliance towards these standards over 
its life cycle. Critical to the success of the GCCS and DODIIS models is the presence of a 
Management Board to decide deployment readiness. The GCCS and DODIIS models place 
more of the program management responsibility for scheduling, integration, and configuration 
management on the Government. 

6.6 Oversight 

Background. The AC2ISRC charter, dated 4 December 1998, ascribes certain Air Staff like 
functions to the AC2ISRC. Examples include the following mission statement excerpts: 

“AC2ISRC serves as the lead organization to integrate and influence C 2 and intelligence, 
surveillance, and reconnaissance (ISR) for the Air Force. Primary tasks are to: 

• Integrate air and space command and control, intelligence, surveillance, and reconnaissance 
operational and delegated systems architectures, roadmaps, requirements and standards in a 
continuing drive toward commonality, maximizing efficiency and reducing duplication of effort. 

• Build aerospace C 2 and ISR modernization strategies, integrated mission area plans (MAPs), 
investment plans/divestment strategies, appropriate C 4 I support plans, and associated 
programming documents that ensure Air Force C 2 and ISR will meet the challenges of Global 
Engagement and Joint Vision 2010 and beyond. 

• Ensure roadmaps, requirements, and the operational and delegated systems architectures are 
linked to the current Air Force Modernization Planning Process, the Air Force Strategic Plan, and 
Thrust Area Transformation Plans, or their future evolutions.” 

In addition, among the Center’s responsibilities delineated in this same charter are: 

• “Architectures. AC2ISRC will develop and maintain near term and long-term C 2 and ISR 
operational architectures for the Deputy Chief of Staff, Air and Space Operations (AF/XO), to 
include baselining Air Force fixed and deployable command centers. AC2ISRC will integrate 
major command (MAJCOM)/field operating agency (FOA) inputs in the design and management 
of the C 2 and ISR system-of-systems architecture in conjunction with the acquisition community. 
Operational architectures will be developed in accordance with the DoD command, control, 
communication, computer, intelligence, surveillance, and reconnaissance (C 4 ISR) Architecture 
Framework document.” 

• “Strategic planning. AC2ISRC will lead the Air Force C 2 and ISR mission area planning 
processes, and produce the associated C 2 MAPs, ISR MAPs, an integrated C 2 and ISR roadmap, 
and other planning documents, to include C 2 and ISR investment plans/divestment strategies. 
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AC2ISRC will coordinate on all Air Force C 4 I Support Plans and, when appropriate, lead the 
development of C 4 I Support Plans. AC2ISRC will ensure C 4 I Support Plans are complied with, 
especially in the area of interoperability and bandwidth and frequency spectrum utilization. 
AC2ISRC will ensure all Air Force C 2 and ISR acquisitions conform to interoperability standards 
required for joint certification. AC2ISRC will also establish liaison with DIA, the National 
Reconnaissance Office, NSA and NIMA to accomplish cooperative planning.” 

• “Program Objective Memorandum (POM) responsibilities. AC2ISRC will build and submit 
an integrated POM for aerospace C 2 and ISR forces with MAJCOM/FOA input and coordination. 
To accomplish this, AC2ISRC will: 

- Develop a strategic/long range vision, a C 2 and ISR roadmap and an investment 
plan/divestment strategy, and serve as the MAJCOM/FOAs’ primary advocate for C 2 and 
ISR. 

- Build an integrated POM that reflects the roadmap and investment plan/divestment strategy, 
and assess MAJCOM/FOA compliance with the roadmap. All interested Air Force C 2 and 
ISR parties will be included in a deliberative, collaborative board structure for building the 
POM input. In the event of disagreement, all parties will attempt to reconcile differences 
between the MAJCOM POM and the integrated POM before submission to the Air Staff. In 
all cases, AC2ISRC will submit an integrated POM recommendation that meets HQ Air 
Force guidance. AC2ISRC will also include with this POM a C 2 and ISR update that will 
include the status of each program and a reconciliation between the C 2 and ISR roadmap and 
each C 2 and ISR program. 

- Review and provide recommended Air Force input to planning and programming guidance 
documents for the intelligence community. These include the Joint Intelligence Guidance for 
National Foreign Intelligence Program, the Joint Military Intelligence Program, and the 
Tactical Intelligence and Related Activities aggregation; the Program Manager’s Guidance 
for the General Defense Intelligence Program; and any other pertinent documentation which 
may be issued by the Office of the Secretary of Defense (OSD) or national intelligence 
program managers. Through these reviews and comments, ensure that Air Force programs 
and capabilities continue to be interoperable with national capabilities and in compliance with 
national-level architectures and standards. 

- In conjunction with the appropriate Air Force component, assess the ability of aerospace C 2 
and ISR POM submissions to meet the CINCs’ identified needs and priorities. AC2ISRC 
will synchronize Air Force C 2 and ISR programs with Joint warfighting requirements to the 
maximum extent possible. 

- Maintain visibility of the execution and budget years. 

- When requested, attend meetings of the Air Force Planning Board of Directors, and serve as 
an advisor to the Air Force Board and Council.” 

Discussion. In executing its POM responsibility the Center functions almost exactly as the Air 
Staff Panel Structure in that MAJCOM inputs are received, reviewed, and integrated with other 
MAJCOM inputs; measured against a funding level; and then submitted as a balanced program, 
recommending funding levels for O&M and modernization. It is not, however, treated as such 
by the Air Staff, which receives the input and then refers it to the usual Panel/Board Structure for 
dissection. These panels have important responsibilities, but an integrated C 2 system is not 
among them. 

The POM structure is the foundation on which the Integrated C System is built. Recent events, 
most noticeably the 2002 POM submission, indicate that the current Air Force structure, as noted 
above, is not conducive to supporting or modernizing our C 2 structure. AC2ISRC POM input, 

6-14 



generally praised as a balanced, well thought out, integrated effort, was basically altered at Air 
Force level. Suggested offsets were taken, but not used to source other C 2 elements. The 
AC2ISRC budget was downsized by approximately 6 percent in an era where information 
management technology has been demonstrated to be a force multiplier in both military and 
commercial enterprises. While this paper is not to suggest that AC2ISRC should be immune 
from review, it does suggest that the AC2ISRC needs a senior champion on the Air Staff to 
assure C receives due consideration in the Air Force priority schema. 


A look at the Navy Staff is instructive here. The Navy C 2 organization is centered on the Chief of 
Naval Operations, N-6. This position is normally a three star flag officer, however, at this time, 
a two star officer, RADM Dick Mayo, fills it. The N-6 is responsible for setting C 2 requirements 
and providing the funding necessary to support the required research and development, 
procurement, and O&M funds to support communication, information warfare, and C 2 programs. 
The requirements for these programs are initiated by and provided to N-6 by the Fleet CINCs. 

N-6 makes the initial attempt to balance any disparities into an equitable program, which is then 
presented to N-8 for evaluation and balance with all other Navy program areas. After the budget 
for Navy C is determined, the funds are provided to the commands which will be responsible for 
procuring the required systems or making the required modifications/modernization. 
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Figure 6-2. Navy C 2 Organization 


2 

As shown in Figure 6-2, the Navy C system is more closely aligned with development/ 
acquisition responsibilities and Navy staff. Recent Navy studies have called for an even stronger 
and higher level organization to oversee C 2 , suggesting the creation of a functional commander 
for operations information and space command. This officer would report to the Three Fleet 
Commanders, in the same manner that the current platform commanders report. 

The Navy model described above, suggests the creation of a command, control, and 
communications “Czar” for the Air Force. This individual would be the focal point for C 2 on the 
Air Staff and assure that C has the appropriate priority in the Air Force budget. A further and 
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necessary function of the command control and communications “Czar” would be to assure that 
the Command (CAF, SPACECOM, USSTRATCOM, Air Mobility Command) and functional 
(logistics, personnel, medical, finance) C 2 systems do not become (or continue to be) 
individually and collectively stovepiped but move toward appropriate levels of integration. 

These are not trivial issues and must be addressed at Air Staff level. Since solutions to C 2 issues 
have proved to be elusive to date, a presence on the Air Force Council seems mandatory. 

We have considered several alternatives to source and place this position: 

• Create a new three star position for C 2 . This provides the positive attributes of unity of purpose, 
right level, show of resolve to attack the C 2 issue. It would require creation of an additional three 
star billet in the Air Force or elimination of a field three star position and movement to 
headquarters. 

• Add C 2 czar duties to the Air Force CIO position. This shows high level resolve but the CIO is 
currently a SAF/AQ additional duty. The incumbent is not and would not be an operator or a 
member of the Air Staff Council. 

• Add the task to AF/XO. Again, this would be an additional duty but would show resolve and 
could be staffed by an operator. It is not at the correct level, as it would undoubtedly be 
delegated below three star level. 

• Use the current AF/SC 3-star billet to create a new position on the Air Staff (with Council 
membership) for C 3 . Move appropriate 3-letters (for example, AF/XOI, AF/XOC) under this 
Deputy Chief of Staff (DCS). Leave appropriate AF/SC three-letters in the DCS. Staff with 
operators with C 2 experience. This provides close to unity of purpose, is at the correct level, 
shows resolve, allows an operationally oriented incumbent, and utilizes an existing billet already 
in HQ Air Force. It eliminates the emphasis on communications and networks which was 
deemed appropriate some time ago. 

Findings. The C 2 system, to attain its potential as a force multiplier and provide flexible, 
deployable capability to CINCs and Air Component Commanders, requires a well-constructed 
modernization program that is sustained over time. To this end, a senior level advocate is needed 
at Air Force level to champion C 2 as a priority among the other Air Force requirements. The 
incumbent would use the AC2ISRC as a primary resource for constructing the C 2 ISR Plan as 
delineated in the AC2ISRC charter. 

Recommendation. A senior level (three star) staff position be created from the existing AF/SC 
position to oversee the important mission of modernizing and sustaining the Air Force C 2 
System. Appropriate resources from the Air Staff should be reassigned. The AC2ISRC would 
be an important part of the incumbent’s operation and the AC2ISRC should be assigned as a 
direct reporting unit (some elements of the AC2ISRC might best remain in Air Combat 
Command [ACC]). 

6.7 Programming and Budgeting 

AC2ISRC is charged with overseeing the entirety of the Air Force C ISR systems. This function 
currently encompasses a budget of approximately $9 billion per year and 117 separate PEs. 

Many of the PEs were created under a different, non-integrated management concept and require 
realignment so that they fit into a logical management structure. This process has started with the 
creation of a PE for the Tactical Air Force’s AOC, but needs to be extended to the remaining PE 
structure. 
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When AC2ISRC was established, a number of PEs were assigned to its stewardship. Some of 
these were clearly part of the AC2ISRC overall mission and were therefore “core”. Others were 
not directly part of AC2ISRC but they had an interest. These were “non-core” and were under 
the Center’s cognizance but were not owned. In total the PEs were about 130 in number. Since 
that time the number has decreased to 117. The size of individual PEs varies widely from 
$500 million per year to $100,000 per year. Given that each PE drives an overhead structure, if 
only in considering funding levels, support at AC2ISRC and in the Pentagon, and justification to 
the Office of Management and Budget and the Congress, some savings in effort if not in people 
can be made by consolidation. In addition, consolidation in some logical sequence will provide 
the much-needed flexibility to quickly react with funding to solve issues or leverage new 
technology without reprogramming. The structure of the consolidation needs careful attention, 
as each of the PEs carries a constituency in terms of military, industrial, and congressional 
proponents. 

Two methods of logically cataloging the C 2 PEs were considered: by node (as in AOC, Control 
and Reporting Center, Airborne Warning and Control System [AWACS], etc.) or by capability 
(as in ground target attack, air target attack, etc.). 

Some pros and cons for each follow: 


NODES 


Pros 


Cons 


Recognizable, physical entity 

Known capability and perceived 
deficiencies 

Easy to understand at all levels 
Flexible reprogramming 
Overarching integration possible 


Exists, therefore good enough 
Already formed opinion as to limitations 

Easy target for detractors 
Integration neglected 


CAPABILITY 


Pros 

System of systems approach 

Difficult to envision, many possible 
solutions to the same question 

What we’re really trying to achieve 
Flexible reprogramming 


Cons 

One system may fit in many capabilities 

Diffusion of funding across many PEs for 
single physical entity 

May not be clear how much is enough 


In order to properly integrate the C 2 system, each program element in the structure must contain 
funding and direction to provide the tools and system management to assure that the program 
element merges within the existing and future operational and system architecture. 


Recommendations 

• Reorganize the PE structure in a node constmct. 
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• Relate PEs that provide operational capabilities through capstone program management directives 
(PMDs), or some similar structure, to assure that focus remains on fielding capabilities, and not 
just systems. 

6.8 Requirements and their Control 
6.8.1 Requirements Process 

The formal Air Force requirements process in use for all systems is a formal, sequential process 
which emphasizes broad-based corporate buy-in regarding broad operational capabilities and 
recommended solutions to mission deficiencies. This process is lengthy, sequential and can take 
from well over a year to several years before a final document is prepared which initiates 
acquisition activity. While this process is appropriate for large, well-defined systems such as 
aircraft, it is not responsive to the rapidly changing environment of information technology (IT) 
acquisition, where several generations of change may be experienced in the time taken to 
articulate a single generation of requirements. 

The concepts of evolutionary acquisition and spiral development (EA/SD) have evolved to 
enable the acquisition system to cope with the accelerated pace of IT development. Similarly, 
this accelerated pace demands a revised requirements process that avoids lock-step sequential 
articulations of required operational capabilities and recommended solutions. 

A requirements process responsive to EA/SD has fundamental characteristics: 

• Iterative through the system lifecycle 

• Intended to be used within EA blocks 

• Focused on rapid delivery 

• Performance traded for cost and schedule control 

• COTS solutions used where feasible 

• Flexible to requirements reflected in business and technical strategies 

• Continuous user and tester involvement 

• Flexible architecture 

• Conducive to experimentation throughout the spiral process 

• Based on new decision points such as stop, continue, change, field, and support 

This process can only work if there is an overarching set of priorities based on operational 
concepts and operational architectures enabling coherent action by a diverse group of 
participants. These operational architectures or operational concepts have not been available to 
the acquisition community in the past. In fact, the TBMCS program did not even have a draft 
operational concept until ACC/CC created a Tiger Team to develop such a document in the 
Spring of 2000— over four years after the (then) $180 million effort was put on contract, and a 
year after the first operational tests. The using and acquisition communities apparently felt that 
a union of the three legacy systems’ CONOPs was sufficient for a description of what should be 
expected from the integrated capabilities. (One has to ask why bother integrating the capabilities 
if that was the case?) There is still no operational architecture for the TBMCS, and to its credit, 
the acquisition community has taken on the task of developing such a document in the absence of 
activity in the user sector. One would suppose that it would normally be the job of the AC2ISRC 
to get such a job done. 
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It is clear that some level of description of the operational architecture desired is required before 
development or integration of capabilities into a C 2 system should be accomplished. But DISA 
and the Joint Staff J3 do not seem to think that necessary for GCCS, as it seems they do not have 
such a roadmap. It remains to be seen how effective that “seat of the pants” approach to 
evolution will be. They appear to determine, on an annual basis, what already developed 
(DII COE compliant) capabilities should be integrated into the GCCS. Approval of these annual 
capability increments then constitutes the Milestone Review by the Milestone Decision 
Authority (MDA) (see DoDD 5000.1). Such an annual process of requirements determination is 
much preferable to the ponderous process we have used on such as TBMCS—where we have 
tried to determine all the required operational performance at the outset, and then embarked on a 
development program to build a system to implement those requirements—while the user 
community is meanwhile modifying its ways of operating, and developing its own hardware and 
software to accommodate those operations. The resulting turmoil of requirements changes 
causes havoc in classical development programs such as TBMCS was. Frequent integration of 
relatively small capability improvements , under the aegis of an evolving operational 
architecture, appears a much better approach. 

Recommendations 

• To realize the Air Force vision of integrated C 2 , needs must be driven by the C 2 concept of 
operations mapped into desired operational capabilities 

• Desired capabilities (referred to as “desirements”) need to be developed through direct 
interactions between “operators” and “acquirers” 

- The desirements must define the capabilities but cannot define how the capability is obtained 

• The 5000 series of DoD Directives need to be revised to reflect the priorities and principles 
described above. In essence, we recommend mining the ACTDs, Lab efforts, JEFX, Industrial 
Developments, etc., for applications which have already been developed and shown to be 
operationally useful—prioritize them—and integrate them into the C 2 system under a level of 
effort funding concept. 

• Do not use the classical, sequential approach: collect system requirements, develop, 
operationally test—this will guarantee the fielding of an obsolete system 

6.8.2 Combat Support Information 

Recent contingency operations such as Desert Storm, Bosnia, and Kosovo have proven the 
necessity to provide the Theater Commander with timely, accurate and trusted information. The 
Expeditionary Aerospace Force (EAF) concept relies on integrated systems to provide an 
enterprise view of combat support information. The core competency to support the EAF is 
Agile Combat Support (ACS). The program to implement the ACS concept is the Global 
Combat Support System-Air Force (GCSS-AF). GCSS-AF is also needed for its contribution to 
rapid mobility and information superiority, two other Air Force core competencies. 

The current process for providing combat support information is too complex, fragmented and 
slow to effectively and efficiently meet warfighter needs. Current data has to be manually 
verified, wasting valuable time, and jeopardizing missions and lives. GCSS-AF must provide 
commanders real-time visibility of relevant blue order of battle information for in-garrison and 
deployed forces for operational missions at any location on the globe. The information assists 
the commander to control resources, plan, train, equip, deploy, employ, sustain, and reconstitute 
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forces across the full spectrum of military operations. The data included in the system vital to 
the success of the mission are shown in Figure 6-3. 

During Kosovo, our current systems, primarily functional stovepipes, did not provide a way to 
access, integrate, or present this information. The support world turned to brute force (phone 
calls, e-mails, and faxes) in an attempt to assemble and verify this critical information. Our 
leadership lost confidence in the information provided. Weapons employment decisions were 
impacted. 

In the summer of 1999, the Air Force CIO established a Tiger Team to pull together the 
requirements and strategy for achieving a strong and successful GCSS-AF. The report of the 
GCSS-AF Requirements Integration Tiger Team was published on 31 August 1999, and is 
included as Appendix 6H of this volume. The acquisition panel strongly supports the Tiger 
Team’s recommendations. 
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Figure 6-3. GCSS-AF Information Cube 


6.9 Development and Integration Standards 

In order to meet the Air Force evolutionary acquisition objectives of deploying new or upgraded 
integrated, and interoperable C 2 capability in a rapid acquisition timeframe (18 months or less); 
making use of the latest commercial IT, there are several processes and conditions that need to 
be employed. We believe these consist of: 
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• Well defined PEs encompassing desired warfighting functionality 

• Stability in PE funding for development, fielding, and sustainment as a function of well defined 
priorities 

• Disciplined requirements generation and control process (CONOPS, operational architecture, 
etc.) involving all stakeholders 

• Defined technical architecture (information technology standards) 

• Educated and disciplined use of the spiral development process 

• Well defined objective system architecture and migration path 

• Integration of test and evaluation (T&E) throughout C 2 development lifecycle 

Many development programs fail or have limited success because one or more of these 
conditions are absent. Each is necessary in some form for successful evolutionary acquisition 
objectives. This section will focus on the items 5 and 6, as the other items are covered in 
subsequent sections of this report. For the purposes of this section, “development” is defined to 
include life cycle evolution of software-intensive systems and/or such related practices as legacy 
system replacement and integration of COTS or government-off-the-shelf components into an 
existing baseline system. 

6.9.1 Evolutionary Acquisition and Spiral Development 

The concepts of the EA/SD process have been studied, experimented, and implemented in 
academia, government, and industry to various degrees. The spiral development is a process 
initially described by Dr. Barry Boehm in the late 1980s. 35 In the 1990s it became more widely 
adopted throughout the software engineering community in various forms. Its basic notion of 
iteration has been generally accepted as preferable to a rigorous sequence of events (“waterfall”) 
or large-scale rollout (“big bang”) of a system. As defined by Boehm, spiral development is “a 
risk-driven process model generator.. .used to guide multi-stakeholder concurrent engineering of 
software-intensive systems.” It is characterized by “a cyclic approach for incrementally growing 
a system’s definition and implementation while decreasing its degree of risk.” It must include “a 
set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually 
satisfactory system solutions.” Commercial IT companies practice EA/SD in some form as 
evidenced by the well know practices of alpha and beta release of products and regular formal 
version release of COTS products with increasing capability. However each company has 
probably developed its own unique versions of the process and the details are not that visible to 
the DoD community. Thus, the model and processes of determining objectives, alternatives, risk 
analysis, artifact development, stakeholder involvement, and decision-making are not visible. 
Although opinions vary on the acquisition system attributes where EA/SD works well, most feel 
there are significant benefits to be gained in its use in the Air Force C 2 domain. The Air Force 
leadership is convinced to the point that EA/SD is now directed for use on all C 2 acquisitions 
unless the user and MDA agree not to use it (Air Force Instruction [AFI] 63-123). 


35 Dr. Barry Boehm, “A Spiral Model of Software Development and Enhancement,” Computer, May 1988, 
pp. 61-72. 
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State of C 2 Evolutionary Acquisition and Spiral Development in the Air Force. The Air 

Force has made an initial start at beginning a formal transition to EA/SD for acquisition of C 2 
systems. Research, results, and guideline documents have been produced: 

• Reducing Air Force Acquisition Response Times: Developing a Fast and Responsive 
Development System, 1 March 2000 (SAF/AQ) 

• Air Force Evolutionary Acquisition Guide Draft, March 2000 (SAF/AQ) 

• AFI 63-123 Evolutionary Acquisition for C 2 Systems, 1 April 2000 (SAF/AQII) 

• Spiral Development Handbook Release 0.1, 1 June 1999 (ESC) 

Some of the shortfalls in these documents are the lack of discussion of the spiral development 
“invariants, variants, and anchor point milestones” as defined by Dr. Boehm. Another shortfall 
is the lack of discussion of the importance of an “architecture first” approach. This doesn’t mean 
that the operational, technical, and system architectures need to be totally defined first, but 
enough of it has to be developed up front to ensure that the first increment is sufficiently robust 
to allow subsequent scaling for additional later increments. Other subjects that are missing 
include explicit process guidance and tools for converging on next level objectives, constraints, 
and alternatives. These documents will need to be supplemented and revised based on 
implementation of recommendations in this report and other research results. 

There are several on-going Air Force C 2 development projects that are explicitly using SD. The 
Global Theater Weather Analysis and Prediction System has completed several successful spirals 
and four incremental deliveries that are operational. This project is both developed by the 
contractor and deployed operationally at the user facility (AFWA) and this perhaps enhanced 
integrated product team (IPT) effectiveness toward user objectives. At one point a mini spiral 
was done in 6 weeks which resulted in an integrated capability to operationally track and predict 
hurricane paths. The Operational Weather Squadron Production System has also completed 
several spirals and is being deployed at the weather squadrons. The Attack Options Decision 
Aid is using SD and has successfully taken part in two JEFX experiments as a component in the 
time-critical target process. Although successful, the team has had some struggle with 
requirements management (growth) and development test and evaluation (DT&E) definition 
tradeoffs as a result of the team learning the spiral development process along the way. The 
JEFX experiments use the spiral process for integrating the experiment C 2 configuration 
infrastructure and initiatives, however very little capability has been transitioned to operational 
use at this point. The Space Weather Analysis and Forecast System is also underway as a spiral 
development and is about to begin DT&E of the first thread. This program has had to resolve an 
issue of the SPO wanting design documentation much like a waterfall development instead of 
waiting for as built design documentation. The Integrated Broadcast System was also started 
under EA/SD but was terminated just prior to completion and deployment of the first increment. 
The failure was in large part due to the lack of or ineffectiveness of the stakeholder IPT members 
in controlling requirements growth and identifying, analyzing, and focusing spiral efforts on the 
risks. 

Perhaps the largest and most successful Air Force development program using spiral 
development (referred to as the Ada Process Model before the term “spiral development” was 
popular) was Command Center Processing and Display System-Replacement (CCPDS-R) for 
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Cheyenne Mountain Upgrade. The CCPDS-R project is discussed and well documented . Its 
Ada Process Model was the predecessor of the Rational Unified Process and University of 
Southern California (USC) MBASE approach, which have been used on a number of successful 
spiral projects 37 . In addition, the CCPDS-R project used a number of working groups (display 
and user interface, algorithm, interface control, security, and test) throughout the life of the 
program with membership from all stakeholders. Decisions from the working groups were 
factored into subsequent design and software builds based on user inputs and risk assessment. 
The spiral process, including an “architecture first” approach, resulted in successful incremental 
delivery of three subsystems (missile warning, forward user processing and display, and 
USSTRATCOM unique) on a fixed price incentive contract. Incremental delivery of operational 
capability within a subsystem was not acceptable because of the nature of the operational 
ITW/AA mission, which could not be performed with a partial capability. 

There are a few other projects that have had SD characteristics even though they didn’t start out 
explicitly with the SD objective. These are Eagle Vision and Air Force Operations Resource 
Management System. Both have produced incremental capabilities using a spiral like process. 

The Air Force also has some success employing evolutionary acquisition/spiral development 
methodologies in other communities. AF/XOI manages several DODIIS intelligence mission 
applications and acts as the executive agent for test and integration for approximately 35 systems 
developed under the General Defense Intelligence Program. The DODIIS development, 
integration, and test model implements the DoDD 5000 and 4630 Acquisition and 
Interoperability Directive, and is consistent with the Clinger-Cohen Act of 1996. Detailed 
DODIIS standards and instructions provide managers, developers and users with guidance 
relative to programming and budgeting, DII compliance, configuration management, test and 
evaluation, training, IT security, and software deployment. This process has been largely 
adopted by DISA for GCCS integration and testing. DODIIS compliance testing occurs in the 
Air Force-managed JITF. Spiral development programs successfully developed, fielded, and 
maintained by the Air Force for DODIIS include the CSP, the ISSE Guard and most recently, 
PROJECT BROADSWORD. 

At this point in time, the overall Air Force EA/SD experience and results are limited and mixed. 
It is likely that a major reason for mixed results is that training and experience at the project IPT 
level has been very limited and thus the individual teams are feeling their way along. 

The 2000 USC/Software Engineering Institute Symposium on Spiral Development. A 

number of organizations are successfully applying the spiral development model (SDM) and 
finding it valuable in addressing such challenges as rapid development, COTS software 
integration, new technologies, and product-line management. Other organizations have 
experienced difficulties with spiral development due to over-relaxed controls, underestimated 
risks, existing sequential development policies, inflexible financing mechanisms, ingrained 
cultures, and confusion about what spiral development is and how to apply it. To attack these 
problems, a workshop was held February 9-11, 2000 at the University of Southern California 
under the sponsorship of its Center for Software Engineering (CSE) and the Software 
Engineering Institute (SEI) of Carnegie Mellon University. 


36 W.E. Royce, Software Project Management: A Unified Framework, Addison Wesley, 1998. 

37 Boehm et al., “Using the Win-Win Spiral Model: A Case Study,” IEEE Computer, July 1998, pp.33-44. 

6-23 



The Workshop objectives: 

• Clarify the nature of spiral development 

• Create a common understanding of the current state of the practice (“as-is”) 

• Share experiences in applying it in various situations 

• Identify its critical success factors 

• Create a vision of best practice (“to be”) 

• Identify and address institutional barriers/inhibitors to successful spiral usage such as policy, 
financial, or cultural constraints 

The results of the workshop are documented in “The 2000 USC-SEI Workshop on Spiral 
Development” March 2000, report number CMU/SEI 00-SR-06. The report can be accessed on 
the web at http://www.sei.cmu.edu/activities/cbs/spiral2000. The workshop participants and 
briefings were from academia, government, and commercial and DoD contractors. None of the 
workshop participants represented DoD organizations that actually used software developed with 
the spiral approach. This suggests that the user community has had little experience with 
products delivered under EA/SD, or is not yet aware of the large opportunity it affords them to 
influence near term delivered capabilities. A brief summary of key issues and recommendations 
from the workshop follows. 

Dr. Boehm opened the workshop with a presentation on the following key concepts referred to as 
invariants: 

• Concurrent determination of all key artifacts. Concurrent determination of all key artifacts 
means that the concept of operations, requirements, design, and code are all progressively defined 
as the system evolves through the spirals. This is essential to avoid premature commitment to 
system requirements, design, use of COTS, and cost/schedule/performance. The relative amount 
of each artifact developed in a specific spiral increment varies based on risk. 

• Recurring stakeholder review. Recurring stakeholder review of objectives, constraints, 
alternative, and risks between spiral increments is an essential element. This avoids wasting effort 
in elaborating alternatives that will be unsatisfactory to the user. 

• Level of activity in each cycle driven by risk. Level of activity in each cycle in each area is 
driven by risk. This is one of the most key differences between spiral development and 
incremental development. By focusing on risk areas and then targeting those areas for further 
development the overall level of risk in the system is driven lower and lower. 

• Degree of detail in all key artifacts driven by risk. For the same reason, the degree of detail in 
each key artifact is also driven by risk 

• Management of stakeholder commitments via anchor points. Using anchor points to 
management of stakeholder commitments is to avoid analysis paralysis, unrealistic expectations, 
requirements creep, architectural drift, unsustainable architectures, and traumatic cutovers. 

• Emphasis on system activities and artifacts versus software artifacts. An emphasis on system 
activities and artifacts versus software artifacts is to avoid premature suboptimization of 
hardware, software and development considerations. The relative amount of hardware versus 
software development, of overall capability, and of degree of productization in each spiral 
increment should vary, as always, based on risk. 

The full briefing can be accessed on the web at http://www.sei.cmu.edu/activities/cbs/spiral2000. 
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The first day and a half of the workshop were devoted to presentations by executives and 
practitioners representing government, commercial users, solution providers, and contractors. In 
retrospect, these presentations evoked these themes and comparisons: 

• The term spiral development is not well defined or understood. For some it means any 
development approach with recurrent planning activities, while others add constraints such as 
“risk-based” and “anchor points.” 

• Spiral development can be sharply defined with invariants and variants ; that is, those aspects that 
are essential in every spiral project and those other aspects which can differ between projects. 

• Spiral development and evolutionary acquisition are different, but related. An evolutionary 
process qualifies technology before embarking on spiral development. 

• Spiral development differs between government organizations and commercial organizations. 

• Some spiral time cycles are still fairly long—two or three years—while others are much shorter— 
two to three months. Typically, longer cycles are found in government. 

• Some of the critical success factors for spiral development: 

- Risk must be managed 

- The culture must be tmsting 

- Stakeholders must be involved 

- The technology must be ready 

- Requirements must be flexible 

The second half of the workshop was devoted to small work group sessions, each addressing a 
different topic. These groups were particularly charged with recommending concrete actions for 
progress. They made forty-nine recommendations which fall into seven categories: 

• Define SDM: Refine and promulgate the definition of the spiral development model. 

• Promote SDM: Spread awareness of the spiral model among developers, managers, and 
executives. 

• Educate about SDM: Provide appropriate courses through universities and professional training 
organizations. 

• Adapt to SDM: Revise policies, processes, and practices to encourage spiral development where 
appropriate. These recommendations were addressed primarily to DoD, but will reward use as a 
checklist for any large organization. 

• Improve SDM: Explore the spiral development model and human behavior to determine what 
improvements are possible and how they should be formulated. 

• Enhance teamwork: Improve teaming techniques, especially as they apply to spiral development. 

• Study SDM: Conduct research to validate the spiral development model, evaluate its potential for 
return on investment, and determine the mutual impacts between it and people. 

For each recommendation, the workgroup proposed an action agent, the person or group most 
likely to be able to take the necessary actions. In general, the Define SDM , Improve SDM , and 
Study SDM actions are expected to be done by universities and research centers, especially 
Center for Software Engineering and SEI; all parties must act on Educate about SDM and 
Promote SDM ; and OSD should Adapt to SDM with respect to DoD policies, processes, and 
practices. 
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Findings 

• The practice of EA/SD in the Air Force (and DoD) is ad hoc and not well defined 

• There is no Air Force funding for implementing EA/SD as a core competency 

• The existing AFI 63-123 on EA/SD does not provide adequate guidance to stakeholders. There is 
no description of the spiral development invariants, variants, and anchor point milestones. There 
is no explicit description of process guidance and tools available for guiding spiral processes and 
converging on next level objectives, constraints, and alternatives. 

• There is no Air Force training program for stakeholders in the effective practice of EA/SD 

• Academia is very interested in working with the Air Force, DoD, and industry in advancing the 
state of EA/SD. 

Recommendations 

• Continue to invest in EA/SD as a core competency 

• Partner with USC and SEI in continued EA/SD development. Enlist USC, SEI, and commercial 
industry support in the review, improvement, and refinement of AFI 63-123 and SD handbooks. 

• The Air Force (and DoD) needs to treat EA/SD as a key engineering/management capability for 
(software intensive) C 2 systems. Task SEI to develop a Capability Maturity Model (CMM) for 
EA/SD. The CMM would apply to all the EA/SD stakeholders, not just industry. 

• Task SEI and ESC to develop a training course in the implementation of EA/SD 

• Provide EA/SD team-building sessions for all new projects/program managers to get projects 
started on an efficient and effective collaborative pathway 

6.9.2 System Architecture 

Although system architecture development is just one of the key activities of spiral development, 
it is important enough to highlight in this section. The C 4 ISR Architecture Framework 2.0 
defines the system architecture view as a description, including graphics, of systems and 
interconnections providing for warfighting functions. For a domain, the systems architecture 
view shows how multiple systems link and interoperate, and may describe the internal 
construction and operations of particular systems within the architecture. For the individual 
system, the system architecture view includes the physical connection, location, and 
identification of key nodes (including materiel-item nodes), circuits, networks, warfighting 
platforms, etc., and it specifies system and component performance parameters (for example, 
mean time between failure, maintainability, availability). The system architecture view 
associates physical resources and their performance attributes to the operational view and its 
requirements following standards defined in the technical architecture. 

As important as the operational and technical architectures are, it is often the system architecture 
that creates problems with C 2 acquisitions. A major part of the system architecture is that of 
automated information system(s) and the corresponding software architecture. These areas of 
the system architecture are often understood by a small group of computer science experts and 
are not well integrated with the rest of the system acquisition. It is also these areas of system 
architecture that have the most impact on the resulting “-ilities” of the system. This is where the 
system attributes of flexibility, scalability, reliability, availability, and security are built in and 
thus, have high leverage for system success or failure. 
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The spiral development process addresses these risks via the anchor point milestones of Life 
Cycle Objectives, Life Cycle Architecture (LCA), and other project unique milestones. The 
process evolves the system architecture, through architectural specifications, prototypes, COTS 
elements, and system architecture instantiations in order to evaluate the architecture attributes 
and manage the risks. For evolving theater C 2 systems, this may mean a periodic spiral of 
updating the objective system architecture and the migration plan from the current architecture to 
the new objective architecture. 

6.9.3 Demonstration Based Development 

The term “demonstration-based development” refers to a set of spirals and decision points within 
an EA increment but after the LCA anchor milestone used to periodically evaluate and validate 
elements of the operational, technical and system architectures and user interface attributes. 

Each demonstration needs to be conducted to exercise an intermediate software build with 
planned threads and scenarios to evaluate a subset of evolving system functions, performance, 
the “-ilities”, and user interface. Continuous user involvement throughout the software life cycle 
is critical to user acceptance of the next fielded version. This typically includes user 
participation in IPTs during the functional requirements analysis, design (particularly for Human 
Systems Interface), training development, and test planning activities. Even more valuable is the 
user feedback from participation in the evolving increment demonstrations. Additional valuable 
benefits from the demonstration spirals are the forced attention to achieving a robust product and 
creating the basis for test agreements before DT&E and operational test and evaluation (OT&E). 

6.10 A Process to Allow Rapid Integration 
6.10.1 Introduction 

One of the major differences between command and control systems evolution and that of 
weapons systems using more established technologies is the pace of technological change. New 
generations of digital hardware, software, and telecommunications technologies are frequently 
available in months as opposed to decades. This rapid evolution requires a command and control 
system evolution process that accommodates such change. The process defined in our current 
basic acquisition publications (for example, DoDD 5000.1) and requirements directives will not 
suffice. As noted above the intelligence and DISA communities have established a process 
which at least appears to do a better job of accommodating rapid evolution. They rely on an 
evolving set of standards for integration (the DII COE in the case of DISA) that allow newly 
developed capabilities (which may have taken years to bring to fruition) to be integrated in 
months into the evolving baseline C 2 or intelligence analysis systems. The classical development 
approach documented in such as 5000.1 assumes that such developments are treated as 
prototypes—and another whole development cycle (consuming again years) is used to integrate 
the new capability into the baseline system. While the DII COE standard may not be the best 
one, such a process appears to be the best available for integration of new capabilities into 
systems such as TBMCS. 

It is the Air Force’s desire to evolve toward web-enabled systems, and minimize the necessity to 
depend on cumbersome client-server architectures such as was the norm when TBMCS was 
started in the early 90s. This evolution is apparently what DISA is planning for the DII COE. It 
would seem worthwhile for Air Force to use DII COE as a near-term platform standard to allow 


6-27 



2 

rapid integration of capabilities into evolving C systems, and to steer the evolution of this 
standard toward one supporting the JBI. Support in the Air Force for the COE has been half¬ 
hearted at best, and it has frequently been treated as a needless and costly encumbrance. We 
need to adopt an approach for the integration of capabilities into joint systems which serve the 
CINCs which allows for integration of appropriate technology as soon as it makes sense to 
introduce it. The “big bang” development and integration approach will not allow that to 
happen. 

6.10.2 Evolutionary Integration—The C 2 Testbed 

An essential element to the development and integration of new C 2 capabilities is a testbed that 
can serve a combined and integrated team of operators, developers, integrators, trainers, 
supporters, and testers to provide a collaborative environment for the evolution of command and 
control. We heard many pleas for location at the Rome AFRL/IF Site and at Hanscom AFB, but 
we see the need to be close to the operators. We believe such a testbed should be established at 
Fangley AFB, under the control of a management board including AC2ISRC, ESC, AFRF and 
Air Force Operational Test and Evaluation Center (AFOTEC) (plus Air Education and Training 
Command training and AFMC logistics personnel), with primary lead by AC2ISRC. While the 
main facility might be at Langley AFB, important satellite development, integration, and 
simulation work can and should take place at other locations (Hanscom AFB, AFRL/IF, 
operational AOCs, etc.) 

Above all, the testbed should be populated with a joint team, a partnership, operating in a 
harmonious relationship between the activities concerned to the common goal of transitioning 
command and control development initiatives and operational concepts to the field. No person is 
in a liaison role: All are IT-operations professionals of high caliber with long-term assignments. 
Figure 6-4 describes the key responsibilities. 

The testbed should be equipped with that equipment representative of fielded equipment, as well 
as that equipment that is necessary to perform the specific functions of the assigned 
responsibilities. 


Operator Responsibilities 

■Maintain CONOPS & Operational Architecture 
■Prioritize desired capabilities 
■Operationally evaluate developed capabilities 
■Plan, program, and budget for personnel and 
support 

■Foster developm ent of new capabilities (ACTDs, 

AOCs, etc.) 


Developer Responsibilities 

■Respond to CONOPS and other user needs 
■Assure technologies available for 
integration 

■Participate in ACTDs, JEFXs, Battlelab 
activities 

■Conduct spiral developm ents as needed 



Integrator Responsibilities 

■Maintain System and Technical Architectures 
■System configuration control 

■Engineering and data assessment, risk analysis 
■Integration and testing 

■Integration of developed capabilities into the baseline 
system 


Ops Tester Responsibilities 

■Participate in engineering process 
■Do main evaluation during development 

.... 1 



+ trainers, sustainers, etc. 


Figure 6-4. Testbed Team Responsibilities 
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The testbed would provide the basis for experimentation with operational and technical concepts, 
as well as the final tests of developments and the integration of capability into the operational 
systems in the field. 

Figure 6-5 depicts the cyclical process. Operators develop operational concepts and 
architectures and identify new technology developments needed. Developers develop 
prototypes, demonstrations, and ACTDs as well as identifying new operational concepts made 
possible by technology advancements. Integrators develop system and technical architectures 
and integrate the new capabilities into the testbed, and later, into the operational system. Testers 
conduct capability testing (on a less formal basis than performance testing), and trainers develop 
training concepts. Much is done in parallel at the testbed, but the result is a cyclical refresh of 
the operational capability in the field. Major physical and functional components of the 
command and control testbed may be physically separated from the main facility. 


Prototypes 


CONOPS-based capability needs 


CAPABILITY 

NEEDS 


OPERATIONAL 

SITES 

NAFs 

JFACCs 

Wings 

Navy C 2 ships... 




Technology 


Developed 
capabilities from 
AFRL, ACTD, 
JEFX, field,... 


Tester 


COMMAND 
& CONTROL TESTBED 


Integrator ^/ 7 



Capability 

tests 


SYSTEM 

UPDATES 


Integration of 
developed capabilities 


Figure 6-5. Evolutionary Integration 


It is the Air Force’s desire to evolve toward web-enabled systems, and minimize the necessity to 
depend on cumbersome client-server architectures such as was the norm when TBMCS was 
started in the early 90s. This evolution is apparently what DISA is planning for the DII COE. It 
would seem worthwhile for Air Force to use DII COE as a near-term platform standard to allow 
rapid integration of capabilities into evolving C 2 systems, and to steer the evolution of this 
standard toward one supporting the JBI. Support in the Air Force for the COE has been half¬ 
hearted at best, and it has frequently been treated as a needless and costly encumbrance. We 
need to adopt an approach for the integration of capabilities into joint systems which serve the 
CINCs which allows for integration of appropriate technology as soon as it makes sense to 
introduce it. The “big bang” development and integration approach will not allow that to 
happen. 
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6.11 Testing 

T&E of C 2 systems is an evolving Air Force area of discipline. Beginning in 1995, the Air Force 
recognized that T&E of C 2 , at the developmental test level was seriously flawed. A series of 
initiatives, stimulated by HQ AF/TE, resulted in establishment of a formal, structured, process- 
oriented T&E team at ESC. A staff element (ESC/TE) is responsible for ensuring that each ESC 
acquisition program develops and implements an adequate test program, incorporating 
appropriate contractor, development and operational testing. 

6.11.1 Development Test and Evaluation 

Development Test (DT), which may include contractor testing, is an integral part of the 
development process, and is primarily conducted in the early phases of a program. It is intended 
to evaluate design approaches, validate analytical models, quantify contract technical 
performance and manufacturing quality, measure progress in system engineering design and 
development, minimize design risks, predict integrated system operational performance, and 
identify system problems to allow for early and timely resolution or correction. OT&E 
(described below) cannot compensate for inadequate DT, since the DT phase is crucial to the 
technical system characterization that must precede OT&E. 

6.11.2 Operational Test and Evaluation 

OT&E, specifically initial OT&E, is the testing and evaluation conducted on production or 
production representative articles to decide whether to field a system or to characterize that 
system’s effectiveness and suitability. In the case of C 2 OT&E, this characterization may be the 
most important function, since a spirally developed system seldom has a Milestone Ill-type 
episodic decision point. It is also important to note that OT&E is concerned with the use of the 
system in its intended environment and may evaluate system interfaces and performance even if 
those parameters were not included in the original specifications and design. 

6.11.3 Complicating Factors 

The classic DT and operational test (OT) structures described above were developed in the years 
before the instantiation of the significant acquisition reform activities of the 1990s. Initiatives 
such as COTS, Cost as an Independent Variable, Component Based Design and TSPR, while 
meritorious in many respects, all exert downward pressure on program costs with a concomitant 
pressure to reduce SPO-controlled DT. To the extent that DT is not comprehensive, OT must 
attempt to fill the gap or risk sending an incompletely characterized system to the user. In 
essence, the system must demonstrate stabilized performance in a stressing environment before 
productive dedicated OT can begin. 

6.11.4 CONOPS and Operational Architectures 

With C 2 systems in particular, the T&E concept is heavily dependent upon the intended 
framework for employment. The operational tester cannot adequately characterize a C 2 system 
and its performance unless the user and developer have produced a CONOPS and operational 
architecture which specify the system’s intended use, the projected interfaces, and the planned 
operational benefits of the system. The CONOPS and operational architecture should therefore 
be required elements in the SPO’s certification of readiness for IOT&E. 
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6.11.5 GCCS and T&E 

The GCCS was examined as an exemplar for C 2 acquisition. While GCCS has numerous 
commendable program attributes, replication of that management scheme should avoid the 
following problems. First, there is no written operational architecture for GCCS. As noted 
above, such an architecture is crucial to effective operational evaluation and characterization of 
the deployed system. Second, it is not clear how the developing agency, DISA, conducts formal 
OT&E of deployed systems. This means that there is no stressing evaluation of either the 
complete system or its component parts in advance of actual operations. Extensive DT, 
interoperability, and security testing is accomplished but these essential activities do not 
compensate for the lack of installed, full-up system operational tests. Similarly, DODIIS 
rigorously tests at the component, interoperability, and security levels but also includes AFOTEC 
as the OT agent on many systems of Air Force interest. The DODIIS process is detailed in 
Appendix 6J of this volume. 

6.11.6 Evolutionary Acquisition and Spiral Development 

The Air Force has clearly specified most procedures for EA and SD in AFI 63-123. Left 
unspecified, however, are requirements for operational architectures and CONOPS. As 
discussed above, these elements are crucial to characterization of the system’s effectiveness and 
suitability. Also unspecified is the specific form of OT&E. Unless the Operational Test Agency 
(OTA) is expected to be continuously involved for the life of an EA system, the architecture or 
CONOPS must indicate when and where capability improvements are expected. The OTA can 
then plan episodic events and subsequent realistic assessments of delivered operational 
effectiveness and suitability. 

6.11.7 Findings and Recommendations 

• An adequate CONOPS and operational architecture must be specified as part the Certification of 
Readiness for OT&E 

• The current ESC/TE reinvigoration of T&E should be supported and those ESC programs without 
formal TE-approved test plans should be required to obtain such approval at an early date 

• PEOs and DACs should ensure that acquisition reform initiatives do not result in less-than- 
adequate DT 

• T&E procedures specifically tailored to support EA/SD should be developed and published by 
HQ U.S. Air Force 

6.12 Infrastructure for Development and Integration 

A major discussion and requirement regarding actual implementation of our recommendations 
has been left until this section. Any major enterprise normally capitalizes a set of facilities and 
operates a set of functions that allow it to pursue its business. In the case of information 
technology-oriented organizations, these are the testing and integration facilities, and the IT- 
unique evaluation, estimation, planning, architecting, and simulation capabilities necessary to the 
successful prosecution and integration of systems in this rapidly changing environment. In the 
early days of acquisition of aircraft, the military invested, and still does, in major simulation and 
evaluation capabilities—in the Air Force principally at Wright-Patterson, Eglin, and Edwards 
AFBs. In addition, with the inception of major new technologies in recent years, very significant 
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new investments were made in signature, electronic warfare, and other lethal and non-lethal 
evaluation capabilities—often Government owned and operated. 

For some reason “the system” in the Air Force has not perceived the need for similar investment 
in the rapidly evolving and high leverage field of information technology. Our C 2 systems are 
therefore developed on a piecemeal, contractor-oriented basis, leading to the very stovepipes we 
are trying so assiduously to avoid. Facilities such as the Modeling, Analysis, and Simulation 
Center (MASC) and C 2 Unified Battlespace Environment (CUBE) at ESC have literally been 
bought with savings on the base electric and heating bills when winters were unexpectedly mild. 
Hardly the way to run a business! Indeed, the operating Commands have in all cases established 
capabilities which are much superior to anything that the C 2 development community has—and 
it has been done mostly with O&M money. 

If we want to continue the stovepiping of Air Force C , then that is the way to go about it—to let 
the operating commands “do their own thing”. We have done a top-level estimate of the kind of 
annual budget that should be provided to an organization such as ESC to allow it to operate in a 
fashion similar to the DISA’s JIEO (see 6.5.1 above). A separate program element and budget, 
starting at approximately $66 million and leveling at $60 million annually should be instituted, 
advocated and defended by the Commander, AFMC, to allow ESC to build and maintain a 
proper infrastructure to accomplish its job. This would allow establishment of the following 
capabilities to support Air Force C 2 evolution: 

1. Enterprise and Domain Architectures: Development/Sustainment 

Realizing an integrated C system with a common infrastructure depends upon an overall 
scoping and definition of capabilities that minimize duplication and maximize mutual utility 
among the capabilities. This is a key role of “architecture.” Specifically, AFI 33-124, Enterprise 
Information Technology Architectures, recognizes three levels of architecture: enterprise, domain 
and program. The DoD C 4 ISR Architecture Framework specifies the format for the products 
expressing military architectures. Responsibility for these architecture products resides with the 
MAJCOMs and acquisition agencies (per AFI 33-124). ESC and AC2ISRC, as the principal 
centers responsible for C 2 , must prepare and coordinate the pertinent architecture products for the 
integrated C 2 system and its infrastructure. 

2. Integration and Interoperability (I&I): Assurance and Certification Testing Development 

It is necessary to have a state-of-the-art facility (CUBE) to support the development, integration, 
test, certification, and sustainment of integrated and interoperable C 2 weapon systems for the Air 
Force and DoD. The CUBE is augmented with a state-of-the-art MASC facility to support the 
development, integration, test, certification, and sustainment of integrated and interoperable C 2 
weapon systems. These capabilities provide the basis for implementing Simulation Based 
Acquisition as an integral part of building in integration and interoperability to the IC 2 from the 
beginning of a new program or modification of an existing system. In addition these capabilities 
provides the Air Force Linkage to the Joint Distributed Engineering Plant for integration of Air 
Force C 2 systems with Navy and Army C 2 elements and supports formal interoperability 
certification and testing activities for Air Force C 2 systems. 

3. Collaborative Tools in Support of Infrastructure Defmition/Development 
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Infrastructure definition and development cannot be a stovepipe activity. It requires considerable 
interaction among all Air Force developers, testers, sustainers, and the user. Also, given the vast 
scope and amount of information needed it must have automated support. The state of 
collaborative tools is such that we can take advantage of them to assist in this activity. 

In order to coordinate activities across warfighters, developers, testers, and sustainers there is a 
huge requirement to have information updated and current. Use of portal technology, 
collaboration tools will allow this information sharing. It may also allow an online 
troubleshooting capability, help, and configuration management of the infrastructure. Building 
on other activities such as the JBC collaborative tools evaluation and the Air Force Portal 
development. This task will allow the development of a collaborative capability for coordination 
of infrastructure activities. 

4. Information Assurance (IA) Support 

The need for effective IA measures has been demonstrated many times recently, as a result of 
virus and hacker attacks. In order to respond to these attacks, the Air Force needs a coordinated 
effort across all the systems that comprise its Integrated C 2 enterprise. The purpose of this set of 
tasks is to define and execute that coordinated effort. 

Implementation of IA in Air Force systems should be executed in accordance with the DoD 
Defense in Depth concepts and principles in order to protect the entire Integrated C 2 enterprise at 
minimum cost. In addition, this implementation must be accomplished in a coordinated fashion 
among all systems that make up the IC 2 enterprise by developing a vision architecture and 
program roadmaps. Finally, we have to ensure the products that are fielded are adequately tested 
to avoid interoperability problems and are accompanied with guidance for field personnel on 
their use. 

5. Commercial Technology and Innovation Exploitation 

Realizing an integrated C system built on a common (supporting) IT infrastructure depends 
upon the continuing discovery and exploitation of emerging commercial information 
technologies and innovative approaches to mission satisfaction. The demands on C 4 ISR system 
developers are increasing rapidly due both to a changing threat environment and the desire to 
gain military advantage through the use of advanced technologies. However, while advances in 
IT have great potential, they place great burdens on developers to realize that potential while 
using immature and in many cases unproven products. In addition, these new technologies must 
be coupled with older (legacy) systems. 

Specifically, exploiting commercial technology and experimental innovation in support of 
Integrated Command and Control System realization requires investment in eleven (11) primary 
areas as follows: 

• Web technologies 

• Personal information services 

• COE migration to “all” COTS 

• JBI realization 

• Portal development 

• Wireless/mobile computing-communications 


6-33 




• Advanced knowledge/decision management aides 

• Public key infrastructure 

• Standards committee influence/participation 

• Commercial IT giants liaison (MS, Sun,.) 

• Joint Technical Architecture-Air Force emerging standards identification/analysis/support 

Funding Summary. Initial estimates of the annual costs to implement and sustain the above- 
defined infrastructure elements are as follows: 

Table 6-1. Annual Cost Estimates of Infrastructure Elements 


Infrastructure Elements 

FY02 

FY03 

FY04 

FY05 

FY06 

FY07 

SYDP 

1. Enterprise and domain architectures: 
development/sustainment 

7.0 

7.0 

7.0 

7.0 

7.0 

7.0 

42.0 

2. I&l: assurance and certification testing 
development 

24.2 

23.5 

22.5 

22.0 

22.0 

22.0 

136.2 

3. Collaborative tools in support of 
infrastructure definition/development 

4.0 

2.7 

0.8 

0.8 

0.8 

0.8 

9.9 

4. IA support 

7.8 

5.8 

5.8 

5.8 

5.8 

5.8 

36.8 

5. Commercial technology and innovation 
exploitation 

23.0 

23.0 

23.0 

23.0 

23.0 

23.0 

138.0 

Totals 

66.0 

62.0 

59.1 

58.6 

58.6 

58.6 

362.9 


Dollars in Millions 


6.13 Summary 

The Air Force’s attention to an appropriate structure to acquire command and control systems is 
far from sufficient. The process, from the attention at Air Staff level, through the PE and panel 
structure, and most importantly in the actual approach to executing acquisitions once the overly 
ponderous requirements and program initiation process is finished is seriously broken. 

By way of example, the process used by the Air Force on the TBMCS Program was much more 
painful and traumatic than it needs to be. The process used by a number of other programs in the 
DoD, exemplified by the GCCS Evolutionary Integration process—where an annual increment 
of capabilities, already developed in laboratories, ACTDs, etc., in accordance with a set of 
standards (for example, the DII COE) allowing efficient and rapid integration into an evolving 
C 2 system (for example, GCCS), best satisfies the desired attributes for acquisition of a major C 2 
system. The Air Force acquisition community has not adopted this sort of approach for reasons 
unknown—in fact the requirement to adhere to standards such as the DII COE has been seen as a 
costly and unnecessary one. As long as this attitude persists, we will continue to have painful 
and expensive C 2 acquisitions. 

6.14 Summary of Findings 

• There is no clear focal point for Air Force C 2 , much less for TACCS, at the Air Staff level (and 
explicitly on the Air Force Council). 
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• There is no clear definition of the TACCS. CONOPS and operational architectures are 
inadequate. There is no written statement of a TACCS vision nor is there a prioritized list of 
desired capabilities. 

• A cumbersome formal Air Force requirements process hampers responsiveness to user needs and 
technology push. AFI 63-123 (spiral development) addresses this issue, but retains the time- 
consuming process of AFI 10-601. 

• Neither AF/TE nor AFOTEC have published a clear statement of policy regarding OT&E of 
evolutionary acquisition systems. 

• The PE structure for the TACCS is fragmented. 

• Two large C 2 systems, TBMCS and Air Force Mission Support System, have had significant 
performance and delivery problems. Precursor systems were originally developed in the CAF 
and handed off to SAF/AQ and AFMC. Inadequate systems engineering was done on these 
systems at the outset—the objective was to satisfy severe capability needs. 

• The existing Air Force instruction on spiral development does not provide adequate guidance to 
the field. The practice of spiral development in Air Force SPOs is ad hoc and not 
institutionalized. 

• There is no spokesman or advocate for C 2 infrastructure, such as building a global grid or 
defining standards for information exchange. 

• The Chief of Staff of the Air Force (CSAF) has no reporting system or metrics scheme which 
provide an assessment of Air Force progress toward accomplishment of an effective TACCS. 

• Operators and users, as represented by the AC2ISRC, do not demonstrate an appreciation for 
crucial infrastructure issues such as the DII COE and Global Grid. 

• Combat support elements (for example, supply, maintenance, finance, medical, etc.) are not 
adequately considered when developing TACCS capability. 

• The acquisition structure for the TACCS comprises 2 PEOs and 1 DAC. This fragmentation 
precludes coherent acquisition. 

6.15 Recommendations 

• SAF/AQ, AFMC, and AC2ISRC should adopt an acquisition approach for the evolution of C 2 
systems such as TBMCS, based on DISA implementation of evolutionary acquisition for GCCS. 
The major elements are: 

- Establishment of configuration control and integration capability (AFMC, SAF/AQ) 

- The capability to identify (annually) mission application improvements needed in the core 
TACCS, to identify and evaluate candidate (already developed) applications, and to initiate 
developments where they are needed (AC2ISRC) 

- Sustainment funding for integration of mission applications into the TBMCS (mostly 3400 
and 3080) (AFMC and SAF/AQ) 

• SAF/AQ should avoid “big bang” C 2 acquisition programs. 

• HQ Air Force should publish requirements guidance which supports the dynamic nature of 
evolutionary acquisition. 

• AC2ISRC should be tasked to accelerate development and publication of the definitive vision, 
CONOPS and operational architecture for Air Force TACCS. 

• CONOPS’ and operational architectures approved by the sponsoring MAJCOM Commander 
must be required before starting development. An adequate CONOPS and operational 
architecture must be specified as part the Certification of Readiness for OT&E. 
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• CSAF should enjoin MAJCOMs from organic developments of C 2 systems without consideration 
of Air Force-wide system impacts. 

• CSAF should strengthen C 2 advocacy on the Air Force Council. A single focal point is also 
needed to work C 2 issues with DoD, Army, Navy, and the Joint Staff. CSAF should also task this 
advocate with the responsibility of developing and implementing a reporting system which 
characterizes C 2 readiness and progress. 

• The Secretary of the Air Force/CSAF should institutionalize the functions of the Air Force CIO to 
provide the advocacy and responsibilities required by the Clinger-Cohen Act and to be the 
spokesman for the C 2 infrastructure. 

• SAF/AQ should consolidate the TACCS programs into a single (PEO or DAC) portfolio and 
under a single Mission Director. SAF/AQ should also develop a capstone PMD to relate and 
prioritize all those system PMDs which constitute the TACCS. It may also be useful to take the 
following actions: 

- Establish metrics to measure the effectiveness of the current PEO management system as 
opposed to the DAC having C 2 system responsibility 

- Stabilize assignments of PEO/PMs to match milestone/delivery achievements 

• AF/XP, with SAF/AQ and AC2ISRC, should restructure the program elements which constitute 
the TACCS into a relatively small number of individually high value PEs which focus on the 
nodes of the TACCS, their combat capability interrelationships, and their evolutionary 
development. 

• SAF/AQ should task SEI and ESC to develop a CMM for EA/SD leading to a revised AFI and 
formal EA/SD training. AFMC should develop and implement EA/SD training for the 
Acquisition Corps. 

• EA/SD demands an integrated effort of not just the operational testing community, but the 
developmental, contractor and user test communities. AF/TE and AFOTEC should develop, in 
cooperation with ESC/TE, approaches that enhance and support EA/SD acquisition.The current 
ESC/TE reinvigoration of T&E should be supported and those ESC programs without formal 
ESC/TE-approved test plans should be required to obtain such approval at an early date. 

• T&E procedures specifically tailored to support EA/SD should be developed and published by 
HQ Air Force. 

• Designate a champion for GCSS-AF, coordinate and approve the lead agency charter amendment, 
approve resources for this lead agency, establish a single acquisition management organization, 
direct that all Air Force combat support systems integrate into GCSS-AF and comply with its 
standards. 
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Appendix 6A 
Acquisition Panel Charter 


The Acquisition Panel will: 

• Identify the desired attributes of an acquisition process to acquire and evolve components of the 
Joint Tactical Air Command and Control System—with special attention to the decision-aiding 
system(s) supporting the AOC(s). The principal components of the Joint Tactical Air Command 
and Control System are: 

- Sensors and sources of data 

- Communication links 

- The Joint Air Operations Center and associated Air Operations and Control Centers (for 
example, AWACS, Wing Operations Center) 

- Weapons delivery and support systems 

• Work closely with the System Definition Panel to ensure the operators’ needs are addressed. 

• Document the current Air Force acquisition process being used to acquire systems such as 
TBMCS. Investigate alternate acquisition processes, DoD, and other (for example, commercial), 
which may be more appropriate for acquiring the TACCS. Evaluate these processes against the 
attributes described in first bullet above. 

• Describe an appropriate acquisition process to acquire and evolve the TACCS—including 
incorporating the JBI concept. 

• Recommend changes to current Air Force processes to more closely approximate the attributes of 
third bullet above. Identify near term and longer-term actions required. 

Coordinate with other panels where technologies, personnel actions, etc. are needed or 
recommended. 
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Chapter 7 

Linking the Air Force by 2005 


7.1 Introduction 

The Study was given the assignment to look at the solutions to “link the Air Force by 2005” with 
specific reference to the difficulty in attacking mobile targets in Kosovo, as well in other recent 
crises. We established teams to look at the time-critical targeting (TCT) problem generally, as 
well as the datalink problem in particular, with the goal of reducing TCT timelines from hours to 
minutes. 

7.2 Time-Critical Targeting Timelines 
7.2.1 Contributions to Reduce TCT Timelines 

Recent conflicts have highlighted the difficulties in rapidly attacking time-critical targets. The 
timeline from recognition of the existence of a targetable object until the kill is excessively long. 
Experience in Operations Desert Shield, Desert Storm, and Noble Anvil (Kosovo) showed that 
timelines of 4+ hours were typical. The goal expressed by the leadership is to reduce the time 
from target detection to target strike to under 10 minutes from the current multiple hours. The 
Air Force Scientific Advisory Board (SAB) has identified and prioritized solutions to bring the 
timeline down to this goal. 

Figure 7-1 portrays the current and future timeline for targeting time-critical targets as 
experienced in Kosovo. Data for the U-2S sensor processing, exploitation, dissemination 
process was based on analysis of the image analyst and mensuration logs at the Distributed 
Common Ground System (DCGS) at Beale Air Force Base (AFB) and the 20th Intelligence 
Squadron at Offutt AFB by Adroit Systems under contract to the Air Force Studies and Analyses 
Agency. The times attributed to the operational high-level coordination, Combined Aerospace 
Operations Center (CAOC) nomination, target folder preparation, and attack execution phases 
were mostly anecdotal information gathered by the SAB from experienced intelligence, 
surveillance, and reconnaissance (ISR) officers present at the CAOC. The best time case 
indicated is based on strike missions using an F-15E with a Joint Standoff Weapon from combat 
air patrol position with target folder information relayed by data link direct to the F-15E pod. 
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Figure 7-1. TCT Targeting Timeline—Now and Future 


7.2.2 Major TCT Timeline Findings 

The analysis of the time-critical targeting experience led the Study to the following findings: 

• Enhanced sensor coverage (time, space, and phenomenology) is essential. High-altitude, long- 
endurance unmanned aerial vehicle (UAV) systems are sufficiently proven and in many regions 
can provide performance like low Earth satellites. They are the only near-term answer for 
standoff (7 x 24) ISR coverage necessary for defense against time-critical targets. 

• Technology for modular active electronic scan antenna (AESA) ground moving-target indication 
(GMTI)/synthetic aperture radar (SAR) has been developed under the F-22 and Joint Strike 
Fighter (JSF) programs and is ready for development and production for surveillance platforms. 

• The technology of moving-target exploitation (MTE) tools for target recognition and tracking has 
achieved significant progress but needs maturing and further demonstration using AESA 
hardware. 

• The combination of advanced GMTI, high-range-resolution target features and interleaved, 
simultaneous spot (ultrahigh resolution [UHR++]) SAR images from the same platform will 
revolutionize ISR and significantly reduce the tasking, collection, processing, exploitation, and 
dissemination over that of current wide-area imagery schemes. 

• Foliage penetration (FOPEN) GMTI/SAR ultrahigh-frequency (UHF) radar technology is 
available for use as a complementary system with a microwave AESA GMTI/SAR system. 
Significant sharing of common hardware is possible. It is the only system that will provide 
standoff coverage in forested regions. It requires more maturation. 

• Advances in data exploitation (fusion) are required for robust capability. The technology of 
fusion processes for timely, geo-registered multisensor inputs from satellite, aircraft, and 
unattended ground sensors has matured. This includes high-resolution SAR/electro-optical (EO)/ 
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infrared (IR) imagery, moving-target indication/MTE radar, signals intelligence (SIGINT), and 
hyperspectral signatures. Some capabilities are in the pipeline but need testing and fielding 
(MTE, automatic target recognition), and additional capabilities need to be developed for this 
focused fusion capability. Currently fielded sensor control and fusion capabilities are inadequate 
for future Air Force operations in timeliness, accuracy, and completeness. There are some 
emerging fusion (GMTI tracking, all-source track fusion) and sensor tasking/management 
capabilities (multi-asset synchronized planning) that offer enhancements. 

Although these are still short of ultimate needs in fusion and control and in their ties to dynamic 
planning and execution. Presentation and visualization of fused info-products is a neglected area 
and there exists no organized effort to codify or quantify what capabilities are available for 
fusion. Codification and quantification are essential in order to assess areas for further science 
and technology investment and to determine needs for new or augmented sensing capabilities. 

The technology that enables automated target mensuration of any imagery with features by co¬ 
registering it with a precision digital reference imagery and terrain elevation database has 
matured. Further reference development will provide target geo-registration to Earth coordinates 
of a meter or so and significantly change and speed the mensuration process. 

Sensor management problems will be magnified in the TCT context. Semiautomatic tools to aid 
real-time ISR sensor and platform planning and tasking have lagged. 

Semiautomatic aids and processes to do target analysis, mensuration, coordination, and 
nomination in parallel are vitally needed and are key to speeding up time-critical targeting. 

Dedicated time-critical target cells and processes are required (tools, tactics, techniques, 
procedures, training ...). 

Battle damage assessment is a comparatively underdeveloped capability within the larger (and 
itself underdeveloped) area of real-time fusion for operations. Combat assessment tools—that is, 
tools for combined battle damage assessment and responsive tasking—do not exist except as 
created individually by operators. This represents an area—namely, fusion of information and 
dynamic planning—that cuts across standard functional boundaries. Tools and processes to 
provide coordinated, near-real time combat damage assessment, are needed from all imagery, 
including SAR and EO, strike aircraft video, ground target motion (or cessation thereof), and 
pilot reports. 

Use of advanced high-power, high-gain AES A radar systems to provide selective, high-power 
spot jamming for electronic countermeasures (ECM) support is feasible but requires dynamic 
sensor/jammer tasking, planning, and management. 

Automated in-flight target folder preparation and update tools and secure real-time data links to 
strike aircraft are required for dynamic targeting of time-critical targets. 

Continued development of wideband communications beyond line of sight to support remote 
reachback analysis is needed. 

Intelligence preparation of the battlefield (IPB) is critically important to sensor planning, tasking, 
exploitation, and geo-registration. The role of IPB is changing from operations planning to the 
more continuous process needed to support agile and dynamic operations: predictive battlespace 
analysis to support missions such as time-critical targeting and timely precision targeting 
information. Based on a worldwide high-precision, digital foundation database of imagery, 
digital terrain elevation database, digital feature analysis data (DFAD), and other information, it 
will produce terrain delimitation (probability of route and location of command posts, forces, etc.) 
as well as precision geo-registration reference. 

There is a critical need for a complete, dynamically updated, accurate foundation data 
environment that maps the battlespace: ortho-rectified, geo-registered data sets and automated, 
laborless, database maintenance. 
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• High-speed weapons with data links for in-flight retargeting are needed for striking critical 
mobile targets. 

• There is no current capability to display how information operations (IO) can affect the battlefield 
and how such operations can offset metal on target. 

7.2.3 Sensors and Platforms 

The key needed ISR improvement is to have continuously available and readily taskable ISR 
platforms that can stay within rapid access of the target. High-altitude, long-endurance UAVs 
could provide 7-day, 24-hour ISR coverage, and an advanced radar could provide all-weather, 
wide-area GMTI coverage and moving-target recognition as well as simultaneous, interleaved 
high-resolution SAR spot imagery. 

Today’s ISR systems rely heavily on radar imagery because it is the key source to provide the 
necessary all-weather, long-range target recognition and precision location. Imagery, especially 
wide-area imagery, is not rapid either in tasking, collection, processing, exploitation, or 
dissemination, not only because of the very high bandwidth required and the huge data files to be 
searched, but, more important, the very difficult problem involved in machine image recognition 
and analysis. Despite 30 years of research and development in machine target recognition and 
the tremendous increase in computer power, we have not achieved automatic wide-area image 
analysis capability and have just begun to achieve modest semiautomated tools to aid expert 
human image interpreters. The excellent work done over the years in automatic image 
interpretation and target recognition has convinced the community that goals such as rapid 
automatic scanning of 100 square kilometers (sq km) per minute of even high-quality imagery 
(NIIRS 6) is still many years away. Today it takes at least an hour to analyze even small 
10-square-kilometer spot images and provide validated target information and mensurated target 
coordinates. 

7.2.4 Advanced AESA GMTI/SAR 

New advanced GMTI/SAR sensors offer significant breakthroughs in real-time detection, 
accurate location, and target feature information of moving targets; the breakthroughs can 
provide the real-time cue needed to take high-resolution spot imagery needed for the targeting 
process. This moving-target detection process is the experience of every deer hunter who is 
often blind to stationary targets but is rapidly cued by even the slightest motion by the deer. 

Once cued, the hunter is able to focus precisely on the target. Advanced GMTI radar can 
provide the needed wide area surveillance for moving-target detection and recognition and can 
provide integrated simultaneous multiple-SAR spot image capability. Unlike imagery, the 
information from a GMTI radar produces only very modest data rates and can be automatically 
processed and analyzed in real time. 

The advanced radar technology is an outgrowth of the AESA technology developed for the F-22 
and JSF fighter programs and now being applied to the radar technology improvement program 
(RTIP). A modular, scaled variant of the AESA radar will have the power and bandwidth to 
provide continuous tracking of thousands of targets with automatic recognition of vehicles and 
military units. It would be capable of simultaneous interleaved GMTI and UHR SAR modes. 

The dynamic GMTI picture of enemy force movement with simultaneous high-range-resolution 
(HRR) target features would be able to identify target regions for cued, interleaved SAR 
stationary target imagery. The estimated GMTI update rates for an area of 5 sq km to 10,000 sq 
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km is expected to be in the order of 10 to 20 seconds per update for average radiated power of 3 
to 6 kW. This would allow simultaneous 1-2 interleaved SAR spot images and hundreds of 
target recognition measurements without degrading GMTI coverage. The cued SAR spot mode 
would be capable of improved high-resolution imagery, which would allow rapid image 
exploitation and target recognition. 

The target tracking accuracy and probability of track continuity depends heavily on target 
acceleration, foliage, terrain shadowing, traffic density, the number of intersecting roads, etc. 
However, the targeting process can predict some of these factors from IPB terrain and feature 
data and can schedule updates when targets reach more favorable conditions or cease motion and 
allow a SAR image. When conditions improve, the dynamic nature of the GMTI/HRR and spot 
SAR can resolve ambiguities and achieve track or fixed location accuracy necessary for weapon 
attack. 

This significant technical advancement in GMTI radar will provide a major leap ahead in the 
quality and timeliness of battlefield reconnaissance for the dominant battlespace awareness 
needed by the battle commander. Rather than just slowly updating moving dots, advanced 
GMTI radar systems will provide high-update moving-target detection and individual target 
features, providing much higher-quality information about the nature and dynamics of thousands 
of moving targets over large areas. The knowledge of vehicle features coupled with high-update 
track data provides significant information concerning military unit convoy characteristics such 
as number, type, and mix of vehicles; vehicle traffic and passing activities as a function of road 
type; mix of civilian and military traffic; indications of roadblocks, bridges, or other traffic 
constrictions; associated helicopter movement; congregation of vehicles at areas that can be 
command posts or logistics or refueling areas; traffic sources such as known military 
installations; and traffic sinks or destinations that can be associated with military units. 

GMTI radar high-update detections coupled with rapid vehicle feature information is 
significantly different from imagery. Finding stationary enemy targets in large areas with high- 
resolution (at 20 to 200 Mbits per second) imagery can overwhelm the exploitation task and 
requires large numbers of highly trained human image analysts to exploit it. Advanced dynamic 
GMTI radar detection and associated high-resolution target feature information is a fairly low- 
data-rate information stream (hundreds of Kbits per second to a few Mbits per second, depending 
on vehicle count) that can be processed automatically. GMTI track data lends itself to 
background automated analysis tasks such as 

• Counting the number of vehicles as a function of areas or boundaries 

• Determination of sources of target vehicles and their destinations, including the road or path 
taken 

• History of movement over time 

• Target evidence and recognition feature accmal and comparison over time, not just a single 
detection 

Microwave GMTI/SAR give all-weather performance but are unable to penetrate foliage. 

FOPEN radar and/or unattended ground sensors (UGS) and covert radar tags are a necessity if 
foliage is prevalent and the enemy is skilled in employing camouflage, concealment, and 
deception. Recent work holds the promise of supplementing the microwave systems with shared 
receiver, exciter, and processing hardware operating in the UHF band and capable of foliage- 
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penetration GMTI. Such multirole radars would provide cost-effective sensors for long- 
endurance UAVs. The microwave frequency would be employed in open terrain, the UHF in 
foliated regions. The two would cue dynamic management of the two radars and their 
SAR/GMTI modes. 

7.2.5 Intelligence Preparation of the Battlefield 

IPB is a process to analyze the battlefield based on a priori collected, geo-registered, and 
analyzed intelligence, such as imagery intelligence (SAR, visual and multispectral), SIGINT, 
human intelligence, and measures and signatures intelligence. Future IPB can provide 
significantly more intelligence support to the commander than is currently possible. Now IPB is 
driven by operational plan execution. Targeting and target folder development begin with an 
execution (deployment) order, and shortening the time to employment can squeeze out target 
folder update opportunities. Future IPB will need to become continuous both before and 
throughout a conflict and become plan-driven for collection tasking in order to provide 
continuous database maintenance. 

The key to modem IPB is the development of a foundation data environment that includes 

• Ortho-rectified and precisely geo-registered imagery data sets 

• Imagery from all sources for targeting, geo-location, and feature analysis 

• Digital elevation models for targeting, geo-location, and planning 

• DFAD, which includes hydrographic and foliage features and cultural or man-made features such 
as buildings and roads 

• Integration of situational awareness data such as military installations and force location 

• Time record of changes and the effect of weather 

A priori products produced from this foundation data environment include terrain delimitation, 
which provides analysis of avenues of motion based on terrain nature, foliage, water, bridges, 
and class of vehicle. It also provides the digital reference information for precision geo¬ 
registration of tactical imagery. In addition, tactical imagery is analyzed against the database to 
produce large object-level changes such as vehicles, new structures, and earth movement. A 
next level of analyses would be based on current intelligence information on location of forces, 
bases, logistics, enemy objectives, etc. Based on this analyses, sensor tasking for high- 
probability regions could be prepared a priori. 

Future IPB tools must become automated and continuous for automated, laborless database 
maintenance and laborless target folder development and maintenance. 

7.2.6 The Benefit and Impact of Speeding Up the Target Attack Decision Process 

A key benefit of such advanced ISR and IPB input is that the long-endurance, high-altitude radar 
produces sufficient real-time accurate target location and quality that it could allow the 
mensuration, high-level coordination, and target nomination processes at the operations center to 
proceed in parallel with strike approval based on the final rapid, high-resolution image analysis 
for target identification. This would significantly speed the time for putting weapons on target 
compared to the current process, which is highly serial out of necessity. In the TCT quick-strike 
process, it is necessary to provide automated aids and hands-on controls for the warfighter 
charged with making the decision as to when the available information warrants committing 
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weapons against a target that has been detected, identified, tracked, and mensurated. It seems 
intuitive that high-quality, accurate, track data and moving-target recognition data, appropriately 
fused in a multiple-hypothesis tracking system and aided by interleaved very high-resolution spot 
SAR images, can provide a significant step toward the confidence needed in order to proceed 
with parallel commitment of resources. However, the process of making that decision obviously 
involves a number of variables: the probability that the target is indeed a TCT; the value of 
destroying that target; the availability of assets to carry out the attack; the existence of enemy 
defenses that threaten each such asset, and the probabilities of successful mission execution and 
of asset loss for each; the rules of engagement, such as guidelines on risk of collateral damage, 
and estimates of the probability of such damage and of its extent. 

This closely coupled, parallel process raises an entire range of questions and research areas, such 
as what information should be presented so that the warfighter can make a decision quickly and 
correctly, and how should that information be presented in order to provide an information 
system with the right “handling qualities” for the warfighter? What decision aids are useful for 
the warfighter? Can this be done in a way that provides the same sense of command authority to 
the warfighter that digital fly-by-wire systems provide to the pilot? 

7.2.7 Recommendations 

From the discussion above, and preliminary analyses conducted by the Study, the following 
actions can result in a significantly shortened TCT timeline and hence are recommended: 

• Accelerate production of Global Hawk with improved electrical power (Aeronautics Systems 
Center [ASC]/RA) 

• Develop and produce family of modular AESA GMTI/SAR surveillance radars for Global Hawk 
as a part of the RTIP development (Electronic Systems Center [ESCJ/JS with Air Force Research 
Laboratory [AFRL]/SN and ASC/RA) 

• Mature GMTI radar HRR and tracking techniques (AFRL/IF) 

• Develop GMTI FOPEN technology for shared integration with microwave AESA systems of the 
future (AFRL/SN) 

- Continue research and development of semiautomated tools for target recognition, analysis, 
image mensuration, and target geo-registration using a digital foundation reference database 
(AFRL/IF with National Imagery and Mapping Agency [NIMA] and the Defense Advanced 
Research Projects Agency [DARPA]) 

• Develop fusion technology for real-time integration of imagery, SIGINT, UGS, radar tags, and 
EO/IR/hyperspectral (AFRL/IF) 

• Continue development of dedicated TCT cell (tactics, techniques, procedures) (Aerospace 
Command, Control, Intelligence, Surveillance, and Reconnaissance Center [AC2ISRC]) 

• Analyze the status of techniques and aids to parallel the target exploitation, mensuration, 
coordination, and nomination processes (AC2ISRC/ESC/AFRL) 

• Analyze the status of techniques to speed sensor planning and tasking and attack planning and 
execution (AC2ISRC/ESC/AFRL) 

• Assess the development and role of the Air Force in the foundation database for IPB and 
mensuration (AFRL with NIMA, National Reconnaissance Office) 

- Assess tools for automated IPB 
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Develop tools for automated in-flight target folder preparation for targeting and retargeting 
(AFRL/IF) 


• Analyze development and application of data links to speed strike planning, pilot folder 
preparation and update, weapon (AC2ISRC/ESC/AFRL) 

• Pursue development of high-speed weapons with data links for in-flight re-targeting (AFRL with 
DARPA) 

7.3 Data Links 

The “link the Air Force by 2005” theme provides a direct challenge for the aggressive 
implementation of datalink program and an indirect challenge for the datalinks through the 
associated need to quickly attack time critical targets. 

In the late 1950s, Air Force air defense fighters depended on Semi-Automatic Ground 
Environment control systems and datalinked commands to effect continental air defense. First- 
and second-generation data links were installed in hundreds of aircraft to allow simple messages 
relaying target data from ground-control intercept sites. In some cases the ground controllers 
actually took control of the aircraft (or the missile, in the case of BOMARC) and completed the 
intercept. Over time, the population of datalink-equipped Air Force aircraft shrunk substantially. 
In the 1991 SAB Summer Study, “Offboard Sensors to Support Air Combat Operations,” we 
strongly recommended that the Air Force realize the importance and leverage of airborne 
datalink systems and develop, fund, and manage a program to facilitate the transfer of data 
between weapons systems. Yet, during that same year, Air Force senior leadership declared that 
datalinks were unnecessary “because of doctrine.” 38 By 1996, the Air Force had returned to a 
point where only 3 percent of aircraft were equipped with J-series datalinks (Tactical Digital 
Information Link J [TADIL-J] and Variable Message Format [VMF]). 

Since that time, the use of Global Positioning System for navigation and weapons delivery has 
underlined the importance of digital data transfer directly from computer to computer, without 
the difficult process of voice transfer and computer entry of long number strings, underscoring 
the need for digital data links. 

Over the years, the SAB has repeatedly addressed the aircraft datalink. The past SAB studies 
have continually reminded the Air Force to expedite the capability for transfer of digital data to 
and among aircraft. The 1982 SAB Summer Study on “Enhancement of Military Airlift” made a 
considerable number of recommendations for the transition to digital data and the user of data 
links on military airlifters. The 1991 Summer Study, “Offboard Sensors to Support Air Combat 
Operations,” noted that “combat aircraft should be equipped with digital datalinks suitable for 
efficient, countermeasures-protected, low-error information transfer to aircraft systems and 
aircrews at modest data rates” and recommended the acquisition of the Joint Tactical Information 
Distribution System (JTIDS), Information Dissemination Management (IDM), and other radios 
with the appropriate gateway systems. The 1994 Study, “Communications Technology Options 
for Global Air Operations,” noted that “data links are critical to future air operations, imparting 
critical situational, threat, and target information to the warfighter,” further suggesting that the 
Air Force “view the data transfer architecture as a mixture of cost-effective radio solutions 
interconnected by gateways.” 

38 “U.S. Air Force Chiefs, C 3 I Officials Dispute Need for F-15 Datalinks,” Defense News, 8 July 1991. 
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Figure 7-2 depicts the notional architecture developed in the 1994 Study. The 1996 Study, 
“Vision of Aerospace Command and Control for the 21 st Century,” said, “The Air Force should 
move away from the heavy reliance on voice communications, especially to the cockpit, and 
move to more capable linked data systems such as Link-16.” The 1997 Study, “Global Air 
Navigation,” noted that “data link transmission provides for a substantial improvement in the 
effectiveness of information transfer, greatly reducing the errors and confusion associated with 
voice transmissions. Moreover, the efficiency is similarly much greater, probably to a factor 
of 100:1, especially those data transfer actions which are associated with the transfer of 
‘numbers’ related with, for example, target location and character.” 


Global Grid 



In Joint Expeditionary Force Experiment 2000, we were able to hear the flight lead air crews 
debrief the mobile target (time-critical target) attack missions with nearly universal success with, 
and support for, use of the variety of data links on the fighter, bomber, command and control 
(C ), and surveillance aircraft involved. The variety of datalink systems was a challenge, but the 
challenge was met with the Talon Gateway system developed and demonstrated there but the 
Space Warfare Center. The key message was that datalinks are important to effective air 
operations, and the Air Force must establish a serious program to provide data transfer capability 
to and among aircraft. 

The historic lack of acceptance of data links has not slowed their development to support special 
missions. In fact, the number of different data links in use by the Air Force is relatively large. 
Tables 7-1 thru 7-4 list many of those in current use across the Department of Defense (DoD), of 
which the Air Force uses a substantial fraction. Table 7-6 illustrates the commonality that is 
currently planned between Air Force C 2 systems and both combat aircraft and ISR platforms. 

39 Adapted from the 1994 SAB Study, “Communications Technology Options for Global Air Operations.” 
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DoD Directive (DoDD) 4630.5 contains basic policy regarding command, control, 
communications, and intelligence (C 3 I) compatibility, interoperability, and integration, which 
includes C 3 I tactical data links. DoD policy designates Link-16 as the primary tactical data link 
for all Service and Defense Agency C 2 , intelligence, and, where practical, weapon system 
applications, unless an exception is granted. The policy contained in DoDD-4630.5 expands and 
reinforces the Assistant Secretary of Defense (C 3 I) Common Data Link (CDL) policy 
memorandum of 13 December 1991, which stated that “unprocessed, broadband, imagery and 
signals intelligence data are required to be provided through CDL to intelligence data 
processing centers. All processed information will be disseminated through Link-16 to permit 
standardized, interoperable, data link support directly to the operator on the battlefield .” 

The Air Force commitment to datalinks has been strengthening, and current plans and budgets 
reflect the intent to field 3372 platforms (aircraft and command nodes) equipped with J-Series 
datalinks by 2015. The installation rate funded by the current (FY00) budget (as indicated by the 
Program Objective Memorandum [POM] submission and reported in the Joint Tactical Data 
Link Management Plan) is shown in Table 7-5 and Figure 7-3. The challenge presented to this 
study was to suggest ways to accelerate this plan and to achieve the “linking of the Air Force” by 
2005. 



Fiscal Year 


Figure 7-3. J-Series Datalinks Planned for Installation in Air Force Aircraft 
(per the Joint Tactical Data Link Master Plan [JTDLMP]) 


It was not possible during the study period to address the engineering (hardware and software) 
issues across the fleet. The study did, however, make it very clear that a dedicated engineer- 
operational team should devote the extensive time necessary to determine the proper hardware 
and software concept of operations approach. This detailed analysis by the Air Force is critical 
to determining the proper approach to gaining digital message connectivity between combat 
elements. The only viable alternative that we can suggest (and one that is subject to further 
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investigation and validation) is to install SADL terminals compatible with TADIL-J in 877 F-16 
Block 40 and Block 50 aircraft starting in 2002 and to simultaneously develop and field 
gateways between Link-16 and SADL. This option could allow an acceleration of TADIL-J 
implementation. When MIDS terminals are installed in these aircraft, the SADL terminals can 
be removed (and potentially returned to the Army). 

If the Link-16/SADL option is implemented, Figure 7-4 illustrates the resulting increase in the 
number of TADIL-J equipped aircraft from an already accelerated installation schedule (relative 
to the schedule laid out in the JTDLMP). 
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Figure 7-4. Datalink Equipped Aircraft Under Current and Alternative Installation Schedules 


-•-Total Datalink Equipped Aircraft 

(Link-16 + SADL Accelerated Installation) 
-■-Total Datalink Equipped Aircraft 

(Link-16 + SADL under Baseline Plan) 

Total Cost: $30-50M; Includes 
Gp-A, Gp-B, installation, 
gateway development, 
production, and installation 



Assumptions: Install SADL in 
F-16 Blk 40/50 starting in 2002 
(same FY as MIDS installs 
begin) and complete field 
mods in 24 months; take 
SADL out when MIDS is 
installed 
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From a longer-term perspective, there are opportunities to rationalize the collection of Air Force 
data links. One obstacle to changing out old data links has been the need to maintain 
compatibility between existing platforms and their ground stations (or among a collection of 
platforms) while fitting the data links into the space, weight, power, and frequency allocation 
limitations of existing systems. 

The fact that installation of each data link is funded by the platform program rather than by an 
integrated data link program office has contributed substantially to delays in fielding a fully 
connected Air Force. One of the conclusions of this study is that the Air Force should establish a 
single manager for data links and put the budget for all installations in the data link program 
rather than spreading it across the multiple platform programs. 
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Table 7-1. Tactical Data Links Managed by the JTDLMP 


Army Tactical Data Link (ATDL-1) 

Cooperative Engagement Capability (CEC) 

Forward Area Air Defense (FAAD) Data Link (FDL) 

Ground Based Data Link (GBDL) 

Interim JTIDS Message Specification (IJMS) 

Intra Vehicular Info System (IVIS) 

Link 22 

Marine Tactical System (MTS) 

Patriot Automated Digital Information Link (PADIL) 

Tactical Fire Direction System (TACFIRE) 

Integrated Broadcast Service (IBS) Note: Tactical Information 
Broadcast Service, Tactical Data Distribution System, Tactical 
Reconnaissance Intelligence System, and Near-Real Time 
Dissemination are planned for migration to IBS, and the IBS data link 
is planned to transition to the J-series family of messages 

TADIL-A (Link-11) 

TADIL- B (Link-1 IB) 

TADIL-C (Link-4A) 

TADIL-J (Link-16) 

Variable Message Format 

SADL 
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Table 7-2. CDL Family Tactical Data Links Not Managed by the JTDLMP 


Airborne Information Transfer (ABIT) 

Advanced Tactical Airborne Reconnaissance System (ATARS) Data Link 

Battle Group Passive Horizon Extension System (BGPHES) Data Link 

Common High-Bandwidth Data Link (CHBDL) 

Guardrail Interoperable Data Link (IDL) 

Guardrail Common Sensor System One (CSS1) Data Link 

Guardrail Common Sensor System Two (CSS2) Data Link 

Guardrail CSS2 Multi-Role Data Link (MRDL) 

Guardrail CSS2 Direct Air to Satellite Relay (DASR) Data Link 

Line of Sight (LOS) Data Link Implementation (LOS tether) 

Lightweight CDL (LWCDL) 

L-52M (SR-71) 

Rivet Reach/Rivet Owl Data Link 

Senior Span 

Senior Spur 

Senior Stretch 

Senior Year IDL 

Space CDL 

TR-1 mode MIST Airborne Data Link 


Table 7-3. Other Collection Data Links Not Managed by the JTDLMP 


Ku-band Satellite Communications (SATCOM) Data Link 
Implementation (UAV) 

Mission Equipment Control Data link (MECDL) 

Radar Data Transmitting Set Data Link 
Surveillance and Control Data Link (SCDL) 

Tactical UAV Video 


UHF SATCOM Data Link Implementation (UAV) 


Table 7-4. Other Non-Collection Datalinks Not Managed by the JTDLMP 


Enhanced Position Location Reporting System (EPLRS) 
Position Location Reporting System (PLRS) 
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7.4 Summary 

For the most part, the time-critical target solution does not involve major technological 
breakthroughs, but rather the dedication and focus to concentrate a few resources and some 
technical and operational thought on the problem. Today’s TCT systems rely heavily on 
imagery because it is the key source to provide the necessary target recognition and identification 
and geo-registered coordinates. Imagery, especially wide-area imagery, is not rapid in tasking, 
collection, processing, exploitation, or dissemination due not only to the very high bandwidth 
required and the huge data files to be searched, but, more important, the very difficult problem 
involved in machine image recognition and analysis. The work in image target recognition has 
to continue, but new advanced GMTI/SAR radar sensors offer significant breakthroughs in real¬ 
time detection, accurate location and target feature information of moving targets that can 
provide the real-time cue needed to take high-resolution spot imagery needed for the targeting 
process. 

The key needed ISR improvement is to have continuously available and readily taskable ISR 
platforms that can stay within rapid access of the target. High-altitude, long-endurance UAV 
platforms could provide 7-day, 24-hour ISR coverage, and an advanced radar could provide all- 
weather, wide-area GMTI coverage and moving-target recognition as well as simultaneous, 
interleaved high-resolution SAR spot imagery. 

The data link problem is long-standing. SAB studies going back to 1991 have continually 
identified the need for concentrated action to gain and integrate effective digital datalink 
systems. There are solutions that capitalize on achieving an operational capability for transfer of 
J-series message sets to attack aircraft. The operational approach to achieving a capability 
within the deploying Aerospace Expeditionary Forces in the most rapid, cost-effective way 
possible should be followed. This will happen only if a single point of management is achieved. 
Clearly, the data link solution consumes money and time, but the tremendous leverage this data 
transfer capability provides makes the investment crucial. 

Linking the Air Force by 2005 will require decisive action on the part of Air Force leadership to 
address fundamental human factors issues that impact the performance, readiness, and 
sustainability of present systems for theater battle management. C 2 must be elevated in status 
and priority to a level consistent with that of other essential weapons systems and warfighting 
functions. The establishment of C 2 as a weapons system has important implications for Air 
Force institutions, organization, and processes used to select, assign, train, and equip C 2 
warfighters. 

“Linking the Air Force by 2005” is critical to conducting air operations against time critical 
targets. It is solvable if, and only if, the Air Force staff drops institutional and political barriers 
and addresses the TCT and associated data link issues with an integrated, aggressive approach. 
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Chapter 8 

Technology and Architecture Issues in Implementing the 
Joint Battlespace InfoSphere (JBI) 


8.1 Introduction 

Successive Air Force Scientific Advisory Board (SAB) studies have progressively defined the 
JBI and recommended a program to implement it. 40 The JBI is a powerful operational view of 
information services to the warfighter. The cited studies provide implementation concepts that 
are carefully grounded in modern information system technology and practice; these concepts 
establish a basis for moving forward to build a JBI that will provide the foundation for 
information-enabled warfare. 

In the course of this study, a set of lower level technical and architectural issues, as well as some 
exciting emerging technological opportunities, have surfaced from a variety of sources. In a 
sense, these involve a bottom-up view, traversing layers of an actual JBI that should be invisible 
to application programmers and users, although they entail some critical acquisition aspects. 
Among the questions the study team has dealt with are: 

1. What is the relationship between the JBI and the Defense Information Infrastmcture Common 
Operating Environment (DII COE)? Given that the DII COE defines a computing platform on 
which programs that implement the JBI could, conceivably, ride, what should be the evolutionary 
path of the DII COE itself? 41 

2. What is the right information model (by implication, far more than simply a data model) for the 
JBI? What is the “object schema” called for in the earlier studies, and how is it to be defined at a 
level of detail sufficient to allow an engineering team to experiment with it or incorporate it in a 
spiral JBI development? 

3. How should the JBI cope with the immense complexity inherent in an information model that 
spans all Services, allies, warfighting and support communities, force echelons, and types of 
operations? As a cautionary tale, the study team was briefed by the Defense Information Systems 
Agency (DISA) that, of the 11,000 or so data elements in the current C 2 CORE model, partial 
joint agreement has been reached on five over the course of years of effort, and prospects for 
further progress are limited. 

4. What should the Air Force be doing today, over the next five years, and in the longer term, to 
establish the information technology foundation of the JBI so that a joint, and fully functional 
infosphere can be brought into existence as soon as possible? 

5. What are the real lessons of the Internet and of commercial projects that have succeeded in 
providing JBI-like information access, strategic and tactical planning, execution management, 
and assessment of functions to their users? More importantly, how do these lessons translate to 
the largely common, but different in important ways, world of command and control (C 2 ), where 


40 SAB Report on “Information Management to Support the Warrior,” SAB-TR-98-02, December 1998; SAB 
Report on “Building the Joint Battlespace InfoSphere,” SAB-TR-99-02, December 1999. 

41 An equally important question may be the relationship of the Department of Defense Global Information Grid 

(GIG) to the JBI. As currently defined, the GIG spans the entire hierarchy of the information infrastmcture that 
supports future forces and thus overlaps significantly with the JBI. The lower layers of the GIG address the kind 
of connectivity and networking fabric upon which a JBI will depend, and the higher layers of the GIG model 
could merge with appropriate views of the JBI. However, this topic is beyond the scope of the present 
discussion. 
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requirements for security, reliability, and timeliness may exceed those of commercial 
applications? 

This chapter documents the outcome of an extended discussion among members of the study 
team and outside experts concerned with information technology (IT) and the JBI. It emphasizes 
the technical aspects of achieving the JBI and is intended to complement the earlier studies. It 
also seeks to provide a summary tutorial on the background, status and applications of the 
primary technologies and concepts of modem IT that bear on the problem. It concludes with a 
recommended set of actions to evolve the existing C 2 environment to the JBI. 

8.2 Summary of the JBI 

The following paragraphs give just enough information to provide context for the present 
discussion. The reader is urged to consult the cited SAB reports for more detail. The JBI is a 
system-of-systems that collects, integrates, aggregates, and distributes information to users at all 
echelons. The central premise is that there be a shared virtual information base, implemented 
through shared access to information provided by the many systems that contribute to the 
infosphere, and with mechanisms that achieve the often described but seldom seen objective of 
providing the right information to the right users at the right places and times. The JBI employs 
four key technologies: 

• Information exchange between individual users and the JBI using a publish/subscribe interface in 
which users send information known to be relevant to the JBI and receive information based on a 
set of user criteria. 

• Transformation of data from multiple sources to a common representation and of data to 
information to knowledge using elemental processes called fuselets. 

• Distributed collaboration via shared, updateable knowledge objects. 

• Templates, associated with assigned units, that describe operational capability, information 
inputs, and information requirements. 

Figure 8-1 is the JBI “logo,” the standard graphical summary of the JBI’s functionality. Around 
the periphery are the warfighting processes that the JBI supports. Within the oval are three 
layers representing the broad categories of input, manipulation, and interaction, with specific 
examples if each. At the core, the JBI employs a Structured Common Representation (SCR) in 
which one or more object schemas are used to define information. A schema prescribes a set of 
attributes associated with a given object class, and a specific object instantiates the schema by 
associating values with these attributes. The schema thus employs metadata to define the 
information objects which, through publish and subscribe actions, are the lifeblood of the JBI. 
This lets the JBI be thought of as an object broker which automates the collection of inf ormation 
that has been published, the distribution of objects in response to queries or subscriptions, and 
the transformation of objects as needed to support collaboration among users. 
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Figure 8-1. The Basic Structure and Primary Functions of the JBI 


The full richness of the JBI construct includes fusion of data streams to create first information 
and then knowledge, sophisticated methods of human-JBI interaction, provisions for security and 
robustness in the face of hostile actions, and many other dimensions of information support to 
operational forces. The SCR will evolve, and its contents will necessarily be highly dynamic, 
growing and changing constantly as new data sources, new user templates, and new information 
objects enter the JBI. However, by centrally managing this complexity, the JBI makes life much 
simpler for individual users and platforms that employ its services. 

As with any complex information system, the JBI requires a variety of views to fully define its 
structure and functions. For purposes of the present discussion, two top level views are 
important. 42 A logical view describes the information content of the JBI and the information 
processes that operate on this content. As discussed in detail later, the essence of this view is an 
information model, and the SCR, the object schemas, the manipulation processes, and the 
information interfaces are critical elements. A physical view has to do with the way the JBI is 
implemented in the form of applications running on platforms, communicating via networks, and 
providing a basis for dealing with the rapid evolution of computer and telecommunications 
technology. Interfaces are still critical, but in this view they take the form of things like 
applications programming interfaces (APIs), messaging interfaces, and network protocols. The 
physical view involves both hardware and software and defines the geographically distributed 
platform that hosts the functionality that creates the logical view as seen by users. A specific 


42 Additional important views focus on security, human-machine interfaces, data management, and other key 
aspects. 
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example is the fact that the shared information base, which is treated in the logical view as a 
single object repository, will physically reside in a variety of data stores associated with assorted 
C nodes, platforms, and systems. 

In the discussion that follows, it is essential to keep clear the distinction between the logical and 
physical views and to be explicit about which of these JBI dimensions is involved in a given 
subject. Our approach is consistent with the Department of Defense (DoD) Command, Control, 
Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C 4 ISR) 
Architecture Framework 43 which defines operational, technical, and system views of an 
architecture. The first of these describes how a given system or system-of-systems looks to an 
operational user and responds to that user’s needs. The second provides a list of approved 
standards for implementing the capability, and is currently documented in the DoD Joint 
Technical Architecture (JTA). 44 The third is the actual system description, or “blueprint,” for 
implementation. Our logical view is primarily an operational architecture perspective, while the 
physical view is concerned with the system architecture, conditioned by a mandate to make 
maximum use of the JTA. 

Among other things, this distinction between logical and physical views helps to decouple the 
DII COE, which is basically part of a platform/physical view, from the current vision of the JBI, 
which takes as its point of departure a logical view of information services to warfighters. Note, 
however, that even these categories are not perfect, and that a certain amount of gray area 
remains between them. For example, the DII COE involves the application of DoD’s Shared 
Data Environment (SHADE), which is an approach to data modeling and thus pertains to a 
logical view. Nonetheless, framing the issues associated with achieving the JBI in terms of 
logical and physical dimensions is very helpful and provides the basic structure for our analysis. 

8.3 The Evolution of Information Technology 

The IT on which modem C relies is largely the product of commercial development and 
applications. However, the DoD strategy for achieving affordable, interoperable, supportable 
information systems has diverged in several important respects from the philosophy and 
practices of the private sector. The DoD strategy is embodied in the DoD C 4 ISR Architecture 
Framework, the JTA, the DII COE, the Global Information Grid (GIG), and multiple directives 
dealing with requirements, acquisition, and interoperability, notably the Chairman Joint Chiefs of 
Staff Instruction 6212.01B. In seeking the best path to exploit IT technologies and products for 
information-enabled warfare, it is useful to put the current situation in historical perspective and 
essential to understand the differences between the DoD approach and that of the global IT 
community. 

8.3.1 Trends in Commercial IT Technology 

Over the last several decades, there has been a pronounced trend in information technology for 
the distinct realms of processing, storage, and networking to come together within an 
infrastructure that harnesses multiple technologies to deliver services to users. Separate groups 
and computer science disciplines have concerned themselves with developing higher 
performance computers, with evolving more efficient data bases, and with designing the data 


43 DoD C 4 1SR Architecture Framework, Version 2, 18 December 1997. 

44 Department of Defense Joint Technical Architecture, Version 3.1, 31 March 2000. 
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communication networks that allow interconnection of these assets. Today, concepts like 
“network computing” and “net-enabled data bases” highlight the fact that all three aspects of 
information infrastructure must be captured in a single, consistent framework. A critical step has 
been the emergence of the concept of metadata, about which much more is said later in this 
discussion, because metadata allows the contents of a data store to be more easily accessed 
through a network transaction. It is the convergence of processors, data bases, and networks in a 
common process that essentially enables the implementation of information infrastructure as a 
set of information services. The structures in which those services are implemented are 
hierarchical. That means that they subsume lower level mechanisms and processes in interfaces 
which conceal (abstract) their detail from users at higher levels. This fundamental concept has 
the power to make possible information sharing and common processes across multiple classes 
of users and diverse computing environments. 

8.3.2 The Difference in the DII COE 45 

The DII COE, the heart of DoD’s interoperability strategy, includes the concept of shared 
services, but focuses on detailed standardization of execution platforms (computers running 
specified operating systems, utilities, shared libraries, and the like) to give applications a fully 
defined operational environment. Indeed, the minimum meaningful level of DII COE 
compliance is the ability of an application program to coexist with others on a platform without 
causing conflicts. 46 The basic concept is a set of applications, implementing C 2 systems and 
functions, riding on a shared common infrastructure that is a point-in-time instantiation of the list 
of standards contained in the JTA. The components of the DII COE platform are largely 
commercial-off-the-shelf (COTS) products that have been segmented according to a set of rules 
so that they can be integrated into the core. The DII COE philosophy is based on the idea that 
interoperability, sharing of applications, economies of scale, long term supportability, and 
similar considerations, demand a comprehensive specification of specific products and standards 
that make up this platform. 

The infrastructure then presents itself to an application programmer in the form of APIs, 
mechanisms like procedure calls for invoking the specific operations of specific versions of 
specific embedded utilities, and the data model embodied in the SHADE. Applications 
programmers need to know in detail the specific functions available from the DII COE platform 
version toward which they are targeted, and subtle changes in those platform details, as the 
incorporated co mm ercial products evolve, have commonly led to problems in development, 
integration, and compatibility of applications across multiple DII COE versions. 

The DII COE platform is comprised of three shared environments as shown in Figure 8-2: 
a common operating environment (COE), co mm on data environment (CDE) and common 
communications environment (CCE). This can be viewed as an approach to the sort of layered 
architecture concepts that have been successful in many networking applications, as described in 
Chapter 3 of this Volume. One practical concern is the fact that if it is desired to extend the 
DII COE platform by adding a new shared component to the core of the environment, a complex 
and time consuming process of segmenting it and passing stringent compatibility testing is 


45 A fuller discussion of the overall study team’s position and recommendations on the DII COE is given in 

Appendix 4C to Chapter 4, the Technology Panel Report. 

46 Eight levels of compliance are defined, with the lowest dealing with documentation practices; the “peaceful 
coexistence” referred to here is defined by Level 5. 
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entailed. Another is that backward compatibility, defined as how many DII COE releases into 
the future the APIs and common services of an earlier version will be supported, has been 
limited. 



C 2 DOMAIN APPLICATIONS 



f Dll COE 


Figure 8-2. The Basic Layered Structure of the Common Operating Environment 


The current DII COE strategy is widely viewed as being on the wrong side of what is commonly 
called the “standards vs. standardization” debate. This means that the DII COE focuses on 
standardizing products rather than on the processes by which information systems interact. 
Certainly, it is quite different from the Internet model, which largely ignores the details of the 
platforms involved in a network, concentrating instead on a set of set of protocols that ensure 
correct information exchange. However, the defects of the DII COE should not obscure the 
importance of layered architectures and the utility, in some circumstances, of a pre-defined 
platform that promotes compatibility of applications. We return to this point later in this chapter 
in discussing the physical implementation of the JBI. 

The Internet conceives of the shared infrastructure as a set of services presented to a user or 
application through an interface that hides (except, perhaps, in a performance sense, such as 
speed of execution) the details of how the service is mechanized. Now, the appropriate standards 
profile is the minimum set needed to employ the available services. Examples would be standard 
formats for describing information (think of hypertext markup language [HTML] to describe a 
web page) and standard protocols for using interaction services (think of the Internet protocol 
stack). There can still be the equivalent of a COE, CDE and CCE. The difference is in how they 
are invoked and how they shield users from the inevitable turnover in the technologies and 
products used to implement them. We propose an approach based on moving from the idea of a 
COE to that of a Common Services Environment (CSE), in which the functions of a COE, CDE 
and CCE are unified through an abstraction interface. 
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This approach is consistent with the idea of decoupling the logical and physical views. 

Something akin to the DII COE, ideally with better provisions for technology refreshment and 
backward compatibility, would continue to establish standards and guidelines for the physical 
layers of the JBI. Similarly, the CSE that is the essence of the logical view must be fully defined 
in terms of rules, constraints, procedures, guidelines and policies, including selective use of 
standards for such things as publish and subscribe services. The goal is to allow the physical and 
logical environments to respond to each other’s evolution while remaining separated in such a 
way that changes in the implementation of one do not force changes in the other. For example, 
as the CSE grows and demands more computational and communications power, it may generate 
requirements for upgrades to the physical environment. Once again, the Internet provides 
powerful evidence that a set of services and their associated interfaces can be maintained across 
many generations of change in the physical platforms on which they ride. 

8.4 Information Services for the JBI 

The first priority concerns the logical view of the JBI, the way in which an efficient information 
model is employed to provide information services. For purposes of the present discussion, an 
information model is defined as: 

A schema for the representation of data, together with the processes which (a) aggregate 
and associate data to create information, (b) fuse and interpret data to create knowledge, 
and (c) import, transform, access, and export data, information and knowledge to meet 
user needs. 

Then the CSE presents the JBI to a user as one or more information service interfaces, defined in 
terms which are transparent to the technology used to implement the underlying platform and 
intuitively natural for applications programmers to use. Since the essence of the JBI concept is 
to allow individual users, platforms, and systems to meet their information needs via a publish 
and subscribe interface to a shared Infosphere, the top level services are simply those described 
in the manipulation layer of Figure 8-1: 

• Publish. The InfoSphere receives and processes data or information transmitted by a platform, 
system or user upon the occurrence of an event which meets the criteria for the action 

• Subscribe/Query. A user, platform or system obtains information presented by the InfoSphere 
when the criteria of a subscription or query are met. A subscription is defined by a standing set of 
criteria; a query is generated by an ad hoc information need. 

• Transform. The InfoSphere activates fuselets that perform the necessary operations to produce 
required information objects and representations 

• Control. The InfoSphere monitors and controls JBI functions 

8.4.1 Information Models 

8.4.1.1 Information in the JBI 

The JBI is predicated on the exchange of messages, for example, documents, reports, or 
commands, within a force. The basic publish/subscribe mechanisms must deal with information 
integrity, security, quality (including timeliness and level of trust), evolution of missions and 
technologies, and access controls or user privileges. The information model on which these 
transactions are based must capture the ways diverse data are imported (including from legacy 
systems), represented, managed, and exported. Current data modeling approaches cannot meet 


8-7 



the JBI need, but furnish a useful starting point in identifying the types of data involved and their 
owners and users. 


In reality, while it is convenient to speak of “the” JBI information model, there will never be a 
final, definitive model because the information basis of warfare is constantly changing. 
Additionally, the very complexity of the JBI information content is likely to demand a number of 
models, each with its own set of meanings (ontology) and a set of callable service interfaces that 
are matched to the needs of various user communities. What’s needed, therefore, is a framework 
and process for the orderly evolution of one or more information models, based on the concepts 
that have made the Internet so successful and on the most promising technologies for defining 
and implementing the object schemas and associated processes. Elements of that framework 
include structure, metadata, and access methods for the JBI information base. For example, 
standards for metadata definition may be useful in preserving compatibility of information 
objects across generations of the information systems which use them. It is critical that the 
information model allow users to tailor information access to their specific needs, for example, 
by presenting information in formats that are native to their legacy systems and to their tactics, 
techniques and procedures. 
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Figure 8-3 The JBI Shared Information Repository Deals with Many Warfighting and Support 
Communities and Supports Tailored Information Products at All Force Echelons 


Figure 8-3 illustrates several aspects of the problem. The shared information repository is shown 
as segmented both by the various communities of interest that contribute to and use the JBI, for 
example, air, land, maritime, and support organizations, and by the organizational hierarchy, 
from overall command down to individual warfighters. Implicit in the JBI is the ability to drill 
down when additional detail is needed and to aggregate data to synthesize higher level views and 
decision aids. The information base then supports the generation of a Family of Integrated 





























Operational Pictures (FIOP), 47 with tailored operational views for individual users; a simple 
example is indicated. 

Figure 8-3 also highlights why it will be important to the success of the JBI to carefully define 
the roles of the individuals and organizations who interact with the shared information base and 
to make them accountable for fulfilling those roles. In terms of the content of the shared 
repository, the basic roles are owner and user. Various areas of content in the shared repository 
will be owned by specific communities of interest and by organizations within those 
communities. Ownership is implicit in the publication of data and information into the 
InfoSphere, whether in the form of updates to data bases or in the form of reports, commands, or 
other messages. Similarly, a platform, system, or individual who accesses the InfoSphere via 
subscribe or query actions has an implicitly defined user role. The ownership role is especially 
important because the integrity and utility of the JBI will, in the final analysis, depend on the 
ability and effort of data owners to ensure the publication of information with the quality needed 
by the warfighters that the JBI supports. 

Another aspect this view of information services is the expectation that users can and will define 
their “business processes” in such a way that the flow of information, the nature of required 
services, and priorities for information support can be articulated and accounted for in the JBI. 

In the commercial world, where much of the technology and many of the concepts that support 
the JBI have emerged, it is widely understood that an enterprise architecture must start with the 
understanding and modeling of business practices and then of the processes that underlie them. 
From this, the supporting information model can be derived. While a business model may seem 
foreign to military C 2 , there are many parallels; an example would be planning at the strategic, 
operational and tactical levels. In fact, this is essentially what is meant by an operational 
architecture, and the increased emphasis now being placed by the Joint Staff and others on 
defining a Joint Operational Architecture, supported by a set of Joint Mission Architectures, is an 
important step in laying the foundation for a JBI. Adopting such a “business” point of view will 
be essential to taking advantage of the new information system paradigm. 

8.4.1.2 Current Data Models 

A huge amount of effort has been expended over many years in building a variety of existing 
data models. The Core Architecture Data Model (CADM) of the C 4 ISR Architecture Framework 
is a compendium of data elements intended to provide the basis for defining Information 
Exchange Requirements in the course of constructing the Operational View of an architecture. 
The Defense Data Dictionary System (DDDS) is intended to be the repository for data element 
definitions across DoD. CADM is for building a database to collect architecture info, some of 
which would be the data models for particular systems. DDDS, on the other hand, is the 
collection of standard data elements from which developers are expected to choose when 
building data models that are later captured in a CADM-based database. 

At the C level, the most common model seems to be C CORE, which is largely an Army data 
model, although the Army also has its Army Integrated Core Data Model and the Land C 2 
Information Exchange Model. The latter is also the North Atlantic Treaty Organization (NATO) 


47 FIOP is the current preferred term for what was formerly labeled the Common Operating Picture and is intended 
to lead eventually to a single Common Relevant Operational Picture. For information, contact Director, 
Interoperability, OUSD(AT&L). 
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reference model known as ADaTP-32 and is due to become a NATO STANAG. Message 
structures like the Link-16 J-series messages and the US Message Transmission Format could 
also be seen as elements of a data model. At the bottom of the modeling pyramid, every 
information system and network has its own data model; an example is the data base design of 
the Air Operations Data Base defined for the Theater Battle Management Core Systems 
(TBMCS). 

In general, the prevailing philosophy of data modelers in the defense community has been to 
pursue comprehensive data element definitions that meet the needs of all warfighters. There are 
two basic reasons why these approaches have been unsuccessful: 

• Like any data dictionary, the resulting models tend to be flat, that is, have no hierarchy or other 
structure, which avoids issues of precedence but makes them extremely cumbersome to use 

• They make no provision for tailoring by user communities, and thus bring on the endless debates 
about details that have, in fact, bedeviled DoD data modelers 

The CADM is drawn up as an entity-relationship diagram. There is generally no way in such 
models to declare domains or to segment the contents to simplify the task of using the content in 
a particular warfighting context. These models are so huge, so complex, and so difficult to keep 
current with evolving systems and operational needs that they are destined to fail. On the other 
hand, hierarchy alone is not sufficient to deal with this level of complexity. The X.500 directory 
services standard defines a sophisticated hierarchy scheme which has proved, in practice, hard to 
manage and has thus far failed to solve the problem of efficiently addressing large numbers of 
network subscribers. This sad history suggests that the problem of dealing with the size and 
diversity of the JBI information base, even as an aggregation of information from multiple 
sources, may prove to be the principal obstacle to achieving its promise. 

8.4.1.3 From Format to Meaning 

A number of technology options have emerged that may help in dealing with this problem. 
Methods for describing, manipulating and presenting data that were not available in earlier 
generations are critical to dealing with the tidal wave of data inundating modem C 2 systems. 

Five essential elements or concepts are format standards, markup languages, metadata, 
middleware, and abstraction. 

Format Standards and Markup Languages. A set of format standards (GIF and JPEG for 
graphics, RTF and TXT for text, etc.) have emerged by consensus in association with popular 
desktop applications. These allow different applications (for example, word processors) to share 
fdes and thus promote openness and innovation because new and better software can be adopted 
without losing legacy data or sacrificing interoperability with users of other software. This 
notion goes an important step further with markup languages which provide a powerful and 
standard way to describe a data object. The best known of these HTML, which essentially 
allows the format (fonts, graphics, etc.) that comprise a web page to be described. Then, in 
principle, any web browser can access the page, and users can freely choose the browser or 
browsers whose features best meet their needs. HTML even enables a class of utility programs 
for designing and implementing web pages, eliminating the need to master the language itself. 

In practice, however, variants of HTML have been promulgated by different vendors that make it 
possible to build pages that don’t work in all browsers. This is an example of an area where a 
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widely supported standard would be a good thing, delivering more in the form of interoperability 
than it costs in the form of limits on innovation. 


Metadata. HTML describes an information object (a web page) in terms of format. The next 
logical step is to enable the interface to an object to describe the content of that object. The idea 
of describing content in some standard, widely understood way, formalized by a language, is 
generalized in the concept known as metadata. Trivially defined as “data about data,” metadata 
has, in fact, multiple meanings in different contexts. In this discussion, it is used in the sense of 
a prescribed way to define a set of attributes of a data object that allow an information process to 
efficiently access and act upon that object. 

The best known example of a metadata implementation is the extensible Markup Language 
(XML) which allows the definition of “tags” that prescribe the format of a set of attributes that 
have been defined for the elements of a data store. These tags are conventionally stored in 
repositories that can be accessed by processes seeking to interact with the data they describe. 
Furthermore, XML facilitates segmentation of a data store into domains that are of interest to 
specific user communities by allowing “namespaces” to be established and assigned to individual 
managers for maintenance and updating. Namespaces allow common XML tags to be reused in 
various contexts while retaining unique identities. Another important ingredient is the use of 
Document Type Definitions (DTDs) that define how the author of the XML tags for a document 
intended them to be interpreted. 

In a C context, the operational domains that are managed by namespaces might be things like air 
operations, meteorology, and intelligence. Clearly, there will be many data items and 
information objects that are used in multiple domains, and careful design of both the information 
base itself and the XML tags for such common content will be very important. DoD, through 
DISA, has established a DII COE XML Registry for tags, data structures, and DTDs, and has 
assigned Designated Managers for a variety of namespaces; for example, the Air Force CDE 
staff is responsible for the Aerospace Operations namespace. It would be logical to define 
namespaces for domains within the JBI, and useful to maintain mappings from these to other 
metadata repositories such as the DII COE XML Registry. 

Taking a track as an example of a data object in a C 2 system, the metadata tag might define 
attributes such as the category of the target, the coordinates of the state vector defining the 
target’s position and movement, the geographical region in which it is located, and timeliness of 
the most recent validated sensor report. A user interested in, say, the mobile surface to air 
missile batteries detected in a specified region in the last 24 hours could use the XML tags to 
rapidly find and access the details of the relevant tracks. A data store that is “XML-enabled” by 
defining namespaces, defining attributes, and writing tags is a long way along the path toward 
being usable in the JBI. With such an interface, the content of a data store is machine-readable, 
and XML thus allows the implementation of syntactic interfaces to data, with attributes of the 
data presented to an external process or user as the basis for interoperability and efficient access. 

This is the fundamental idea behind an XML “wrapper” around an existing data store that allows 
it to become part of a larger repository. These wrappers are defined by DTDs, but in an 
application like the JBI, the DTD content will need to go beyond a simple mapping of the 
various fields in the tags that describe the data. The DTD should also deal with the quality of the 
data in terms of such attributes as timeliness, ownership and the “pedigree” of the data that 
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establishes, among other thing, the level of trust accorded to the data’s source. Approaching 
metadata in this way puts the JBI squarely in the IT mainstream and ensures that its data model 
will be widely understood and easy for application developers to use. 

Segmenting the shared information base into domains will never be precise, because certain 
objects will always be of interest in multiple domains. For example, consider cruise missile 
tracks. Every warfighting community involved in an operational theater is likely to subscribe to 
current information on detected inbound cruise missiles. The JBI information model must ensure 
that the various domains are updated consistently and in real time, even at the expense of some 
duplication of data. This might be implemented as a replication function in which a central 
cruise missile track domain publishes updates to appropriate subscribing domains, so that the 
central track fde ensures consistency and eliminates the propagation of false or uncorrelated 
tracks. 

Middleware and Abstraction. Middleware is used in this discussion in a very general sense to 
designate a broad class of software that mediates between one or more classes of users and a set 
of information services. Middleware can do anything from establishing an intranet for passing 
e-mail and scheduling meetings to mechanizing the processes associated with accessing data and 
scheduling the delivery of products. A fundamental task of JBI middleware will be to ensure 
synchronization and consistency of content across domains and to resolve conflicts such as 
inconsistent reports about an object; if necessary, such situations may require alerting a human 
operator. 

Using tools like metadata and middleware, an information infrastructure can implement one or 
more layers of abstraction. This is much like what the developers of structured programming 
called “information hiding,” and the idea is that those details of a process that an external user 
does not need to know in order to use the process should not be exposed. In defining 
information services, abstraction layers allow a user (which might be a human operator, an 
application program, another data store, or something else) to invoke the service in terms that are 
natural and easy to use. A user who has detected a hostile target might publish the event in terms 
of “an object of class <SA-20> has been detected at coordinates <x, y, z, t>.” Then the JBI 
would send the track update to every user who had subscribed to this class of target and whose 
area of interest overlaps a circle of radius n kilometers, where n is the engagement range of the 
threat system. 

The power and utility of middleware will be greatly extended by the use of agent technology. 
Agents are a complex topic and the subject of a great amount of current research, but the basic 
idea is that of software entities that contain enough intelligence to autonomously perform 
functions on behalf of a user, often with incomplete specification of the task. Agents do things 
like traverse data stores looking for content of interest, not just on the basis of a list of 
parameters but of “understanding” of the true information needs of the user (which might be an 
application program) for which they are acting. 

Future Trends. Syntactic interfaces using XML represent the current state of the art. They are 
the basis for an ongoing revolution in electronic commerce (“business-to-business”), process 
reengineering, and what have come to be known as “enterprise architectures.” XML, or an 
equivalent standard, allows the construction of the attribute/value pairs of an object schema 
under the JBI. However, the next step in the evolution of information models is beginning to 
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take shape. A markup language that makes the content of a data store machine-understandable, 
that is, that presents not only the attributes but the meaning of the information, creates a semantic 
interface. This allows the definition of an ontology, a shared basis of meaning about the content 
of an information store, and is an obvious step in the direction of fully natural interfaces in which 
a user has no need to know the arcane details of computer languages, data structures, and syntax. 
The needs of electronic commerce can be expected to drive rapid progress in this area. 

Such an interface, using middleware based on agent technology, is being explored by the 
Defense Advanced Research Projects Agency (DARPA). The associated language is the 
DARPA Agent Markup Language (DAML), and the goal is to enable agents that not only 
identify but understand data objects and thus allow great improvement in the quality and 
productivity of information services that depend on accessing data. Now, for example, a query 
to the data store could use one or more agents that contain the intelligence to reject data objects 
whose content is not consistent with the needs of a decision aiding tool that initiated the query. 

In the language of the JBI, agent technology may prove to be a powerful way to implement 
fuselets. The full potential of this concept is only beginning to appear. Existing technologies 
such as XML provide a solid basis for the initial implementation of the JBI, but as the generation 
of technology represented by DAML matures and is instantiated in tools and products, the full 
functionality and power of the JBI information model, and the services it empowers, will become 
available. 

8.4.2 The JBI Information Model 

With the above as background, we can discuss the characteristics that the JBI information model 
should possess. The ultimate objective is to present a set of information services to users and 
applications that are robust, policy-compliant, easy to use, interoperable across communities and 
systems, and transparently evolvable with the progress of implementing technology. Key 
attributes are as follows: 

8.4.2.1 Domains 

Information stores and associated processes must allow segmentation into domains to make 
manageable the complexity of the data employed by individual communities and systems. 
Domains also support the need for individual user communities to collect and structure data to 
meet their specific needs and to exercise data ownership. Information sharing across domain 
boundaries must be easy to achieve (for example, a submarine may find itself controlling a 
unmanned aerial vehicle). As noted earlier, XML namespaces and DTDs offer an initial 
approach to achieving this. Note that the two goals specified here are oppositional—segmenting 
information into domains makes it harder to share across domains. Moreover, there will never 
be a clean way to segment data into domains because no two user communities will have the 
same way of parsing data. There must therefore be accompanying middleware for 
synchronization of shared information and resolution of discrepancies. It may prove useful for 
widely shared data and information objects to create centralized data bases which are part of the 
JBI information model, are not user-defined, and are used to replicate consistent updates into 
various domains. 
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8.4.2.2 Structure 

Data is inherently hierarchical. Objects such as messages and platforms derive from higher order 
objects (say, message catalogues and military formations) and imply lower order objects (say, 
fields and subsystems). Whether or not strict object orientation, involving inheritance, 
polymorphism, encapsulation, etc., is employed (previous SAB JBI reports say it need not be), a 
hierarchical data structure is enormously more efficient than a flat one when a search is being 
performed with less-than-complete specification of the information sought. Other kinds of 
structure are also useful. HTML documents use hyperlinks to associate content on various 
pages. Semantic interfaces offer additional possibilities. The point is that the huge, diverse 
content of the JBI shared information repository must be embodied in a structured representation 
if it is to be used with high integrity and in real or near-real time. 

An important, unsolved technical issue is involved here. The JBI construct implies that the 
system can associate a unique identifier with an information object and then be able to find out 
such properties as the object’s location, type, and access control permissions. Despite the efforts 
of bodies such as the Internet Engineering Task Force (IETF) and World Wide Web Consortium 
(W3C), no such information identification method has yet been agreed upon, implemented and 
deployed. One system with the desired properties is the “Handle System” developed by CNRI 
under DARPA sponsorship which has its roots in the digital library community. The JBI must 
have such a capability, and the responsible developing organizations will need to work with the 
IT community and, eventually, choose and implement a suitable method. 

8.4.23 Compatibility with Heterogeneous, Legacy, and Local Data Stores 

For practical reasons, it is unlikely to be feasible that the vast array of legacy data bases be 
translated into an entirely new JBI object schema, certainly not all at once. The information 
model must provide for wrappers, translators (presumably using fuselets), or other mechanisms 
that allow incorporation of such data stores and seamless access to them through the interfaces of 
the information services set. Similarly, there will be circumstances where specialized or 
privileged data must be accommodated in local stores. As a general attribute, the JBI 
information model must provide the facilities that allow heterogeneous data stores to be 
integrated under common abstraction layers and their associated interfaces. Together with 
segmentation, this attribute addresses data ownership and deals with the operational reality that 
various segments of the aggregated data environment will be owned and managed by various 
authorities, each of whom will require appropriate controls over content and not all of whom will 
agree on all terms. 
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Figure 8-4. Structure and Features of a Notional JBI Shared Information Base, Drawn to Emphasize the 

Logical View of the InfoSphere 


Figure 8-4 suggests the nature of a JBI shared database that embodies these principles. This is 
very much a logical view; the physical instantiation will involve a networked ensemble of nodes 
and a highly distributed information processing and storage structure. At the top of the logical 
structure, users see the JBI through a set of information services interfaces for publish, subscribe, 
and query. At the bottom, the owners of various information sets are responsible for updating 
the content of their respective domains. Legacy and new databases are XML-tagged; for the 
former, this provides the necessary wrapper to allow incorporation into the JBI. Middleware is 
responsible for maintaining consistency across domains; for transforming data to a common 
SCR; for aggregation, fusion and processing to yield information and knowledge; and for 
supporting the user interface. As noted earlier, a set of central data bases for data and 
information that is widely shared across domains may be useful. Again, “middleware” is used 
here in a very general sense to refer to the many processes that act on data and information from 
multiple sources and users to knit together JBI functions and services across a heterogeneous and 
distributed physical implementation. 

8.4.2.4 Abstraction 

The information model must present the information base through one or more abstraction layers 
that hide the implementation details. Initially, these will be syntactic interfaces, but semantic 
interfaces should be implemented as the technology matures. Another dimension of abstraction 
is the capability of the JBI information model to aggregate data to create information and to fuse 
and process information to create knowledge. Within the hierarchy of the information model, 
middleware, especially using agents, can construct information and knowledge objects that are 
presented to users at the appropriate service interfaces. 
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8.4.2.5 Management 

The JBI will become perhaps the most critical resource commanders and warfighters have 
available in conducting operations. It will sit at the focus of doctrine, operational priorities, and 
national policy governing the use of military force. Its performance and integrity will largely 
determine success or failure. At the same time, it will be one of the most complex information 
systems ever built. For all these reasons, a critical attribute is the structure that is put in place to 
manage the JBI, both in terms of its real-time operations and in terms of its development, 
evolution, certification and integration with supported forces. The related issue of centralized vs. 
distributed control is discussed in more detail later. 

As shown in Figure 8-1, control is a basic JBI service or function. Perhaps a better term, since 
the JBI will incorporate many systems and information sources, might be “governance.” JBI 
operations will be largely dictated by policies established at various levels of command; 
particularly at the operational and tactical levels, the JBI must allow commanders to adjust their 
policies as the exigencies of an operation dictate. Highly skilled system administrators, 
communication and networking specialists, and other dedicated personnel will be required to 
monitor and control infosphere operations and to diagnose and correct problems. As the 
InfoSphere system-of-systems evolves, continued verification and validation of its hardware and 
software, including accreditation to handle classified information, will be a continuing challenge. 
Diverse, and often conflicting, requirements from various user communities must be harmonized 
and a coherent program implemented to keep the JBI current and supportable. Integration with 
legacy systems, many of which will present proprietary and incompletely documented interfaces, 
will be yet another ongoing challenge. 

The JBI transfers complexity from individual platforms and systems to a shared information 
infrastructure. This has great potential to enhance force effectiveness and to reduce the burden 
on individual users. However, the price to be paid is a very large and complex management task. 
Within the InfoSphere, there will be functional domains, each with its associated control and 
management processes. The challenge of dealing with the federated, system-of-systems nature 
of the JBI while ensuring consistent and robust information services to all users must be treated 
as a central concern in bringing the JBI to reality. 

8.4.2.6 Security 

The JBI interacts with many users and systems, integrates the full panoply of operational and 
intelligence information, and supports the most critical warfighting decisions. The security and 
integrity of its information are critical to combat success. On one hand, the widespread 
information sharing that is inherent in the JBI is likely to introduce vulnerabilities, but on the 
other, centralized control of information may have advantages in providing information 
assurance. The information model must implement applicable security policies, such as support 
for virtual private networks, support for multi-level security, and mechanisms for protection 
against information attacks. 

Security is an extremely complex subject which must be a central focus of the evolution of the 
JBI. The DII COE organization at DISA has placed great emphasis on ensuring the security of 
the platform kernel, which is one important consideration. Other approaches include the concept 
of Proof-Carrying Code, being investigated at Carnegie Mellon University, which offers a way to 
authenticate that a server-provided application is traceable to a trusted source. Various schemes 
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for user authentication, including the DoD initiative in Public Key Infrastructure may also 
contribute, but must be compatible with the realities of the battlefield, including the hazard that 
the credentials of a casualty or prisoner of war may fall into enemy hands. A satisfactory 
security architecture for the JBI will include functionality allocated at every level from the 
platform operating system and network manager to trusted applications and user authentication. 

Rosenthal and Sciore have developed extensions to Structured Query Language (SQL) that 
improve controls over access to the content of a data warehouse. 48 This approach appears well 
matched to distributed data storage and large numbers of users and controlling authorities. 
Techniques such as this will have to be captured and expanded to achieve a robust security 
strategy for the JBI. A careful analysis of vulnerabilities and their mitigation in a JBI is still to 
be accomplished. Security is a very important unsolved problem that needs a great deal of 
attention and high priority for resources. 

8.4.2.7 Consistency and Replication 

The JBI information base will be geographically distributed and multiply instantiated. It is 
essential that the information model provide for replication, synchronization, and consistency 
enforcement across all locations where common data is stored. It’s also important that a 
common modeling approach be used for data coming from various sources and data provided to 
applications. An important aspect is likely to be a Transform Library that contains the 
information on such things as unit conversions (for example, miles to kilometers), file format 
conversions (for example, JPEG to GIF) and communications protocol translations. Such a 
library would be extremely useful in the efficient operation of the fuselets that are responsible for 
the multitude of content transformations required by the JBI. 

8.4.2.8 Quality Assurance 

In the real world, data will be imperfect, whether contaminated by errors, aged beyond allowable 
latency limits, missing parameters, or otherwise deficient. The information model must provide 
for quality checking and allow data to be accessed with appropriate declarations of accuracy, 
timeliness, trust level of the source, and so forth. When the information model yields multiple 
inconsistent answers to a query, the appropriate users and system administrators must be 
informed. 

Another essential aspect of quality relates to the source or pedigree of a given information object. 
The level of trust placed in the source, the inherent quality of the sensor or observer producing 
the data, the extent to which the source has unhindered access to the event or location being 
reported on, and similar factors must be accounted for in assigning a quality metric. This is 
critical when independent or dissimilar information objects must be fused, remembering that the 
optimum fusion method may simply be to pick the best one and that poorer data may simply 
degrade the fused result if used indiscrimately. 

Quality will depend critically on the currency and accuracy of the metadata in the JBI repository. 
Metadata is not static because the information objects themselves will be constantly changing. A 
key function of JBI management will be to ensure adequate provisions for refreshing and 
revalidating metadata. Tools for the development, editing, and export of metadata are beginning 


48 A. Rosenthal and E. Sciore, “View Security as the Basis for Data Warehouse Security,” Proc. Int’l Workshop on 
Design and Management of Data Warehouses (DMDW 2000), 5-6 June 2000, pp. 8-1 to 8-8. 
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to emerge for electronic business and other applications and are likely to be important in dealing 
with this. 

8.4.2.9 Additional Services 

Over and above the five services identified in the manipulation layer of Figure 8-1, higher order 
services are likely to evolve to make the JBI more efficient and useful. A “discovery” service 
would take whatever parameters and criteria a user is able to provide about desired information 
and conduct an intelligent search for content that may be relevant. A “mediation” service would 
map content from various domains and in various formats to a uniform interface understandable 
by all users. A variety of “fusion” services can be envisioned, ranging from association and 
kinematic merging of track updates to combinations of dissimilar or uncorrelated data to produce 
indications and warnings messages or to discover previously undetected associations. 

8.4.2.10 Interfaces 

Last, and most important, the JBI information model(s) must have interfaces that facilitate access 
to services by each user community. This is the essence of ease of use, because good interfaces 
make the details of the information infrastructure transparent to operational users. Properly 
defined and implemented interfaces have far greater impact on the utility of the JBI than the 
details of information manipulation within the infosphere (as one study participant puts it, 
“Interfaces are more important than algorithms.”) For maximum interoperability, the JBI’s 
service interfaces must be implemented in a language that supports a rich array of functionality. 
The best example today is probably SQL, with the good possibility that an XML query language 
will emerge in the near future. Properly implemented metadata supports the generation of 
connectivity parameters to enable efficient and rapid support for publish and subscribe actions. 

8.4.3 Interoperability 

A user or platform interacts with the JBI through an interface defined in terms of publish and 
subscribe actions which invoke the corresponding services of the JBI information model. The 
JBI interface explicitly allows ad hoc queries and might logically be extended to include such 
things as attachments to messages and references to information locations. This is the essence of 
interoperability in a JBI world—each participant deals with a single, well-defined information 
provider instead of with a combinatorially complex set of interfaces to other participants. The 
interface can be thought of in terms of an interface control document (ICD), since all essential 
details of the interaction must be defined, but is fundamentally different from the traditional 
definition of an ICD. Instead of the detailed prescription of signals, bit definitions, and timing 
relationships of a classic ICD, the JBI interface consists of the information service interfaces, 
protocols for the communication services employed, and protocols for security, network 
management, and other aspects of JBI access. 

The interface is hierarchical. As the JBI information model evolves to higher levels of 
abstraction, the top level comes closer to natural language. Here, it is easy to implement both 
command policies for information dissemination and individual user information needs. At 
lower levels, details of the information and data structures, the communications channels, and the 
implementation of security procedures must be dealt with by system designers. At every level of 
the interface, the guiding principle is a fully open, flexible, Internet-like model of interaction that 
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uses appropriate public standards where they apply and defines new ones as needed. The choice 
of standards for publish and subscribe will be especially important. 

8.4.4 Centralized vs. Distributed Control 

There is an inherent tension in the JBI construct between centralized and decentralized control. 
From the perspective of commanders and their forces, it is essential that the JBI be controlled in 
such a way that the quality and consistency of information is assured, command policies are 
uniformly applied, and a fully defined interface is presented to every user. From the perspective 
of the system developer, centralized program management of such a large and diverse system-of- 
systems, built up by the incremental incorporation of many kinds of legacy and new components, 
is almost certainly unworkable. Put simply, the challenge is to make the logical view appear as a 
single, fully integrated information services provider while providing for decentralized execution 
of the physical implementation. 

The solution will emerge as the JBI evolves, but some general principles can be defined. There 
will have to be centralized control of the JBI operational architecture, especially the definition of 
the services interfaces presented to users. There will also have to be mechanisms for 
implementing command policy, for example, for “pushing” certain messages to specified 
recipients. Similarly, the JBI must establish global rules and conventions for the participation of 
incorporated components. An example of this is the DTDs that define the SCR, providing a 
common information representation that all information providers must support. Other globals 
will involve rules for access privileges, definitions of information quality metrics, and any other 
JBI aspects that apply across the involved platforms, systems and users. 

On the other hand, data ownership, interface tailoring for individual users, maintenance of 
individual JBI components, and the like require distributed control of important JBI features. 

The next section of this discussion addresses the physical view of the JBIs and some practical 
considerations involved in building it, which also call for decentralized management. The 
tension will be resolved by allowing decentralized implementation of the JBI under the 
operational architecture and a set of global rules. 

8.5 Physical Implementation of the JBI 

The logical view of the JBI establishes what it looks like to warfighters and, thus, how it 
contributes to information-enabled operations. However, the physical view is what chiefly 
determines the feasibility, complexity and cost of actually building the infosphere. Ultimately, 
the JBI is created by computers and software, networks and data links, human-machine 
interfaces, and other assets which instantiate JBI information services and their interfaces. As 
the earlier JBI studies have stressed, this platform environment must be efficiently designed and 
effectively managed if the goal of seamless, reliable information support to warfighters is to be 
achieved. 

A number of factors make the JBI a formidable undertaking. It must scale effectively to meet the 
needs of a wide range of force packages and missions. The turnover of technology and products 
and the practical constraints of system acquisition mean that the JBI platform will be 
heterogeneous and will continuously evolve. The JBI will be hosted on many types of 
computers, operating environments, and networks, varying from platform to platform and node 
to node. Many pieces, some new and some legacy, must be integrated and must function 

8-19 



cooperatively within operational timelines and with the requisite continuity, reliability, security, 
and quality of service. 

It bears repeating that one of the keys to success will be to decouple the logical view with its 
services and user interfaces from the evolving physical view or platform. In keeping with 
current best practices in the IT world, the logical view of the JBI must be captured in an 
operational or functional architecture that is independent of any particular implementation. Then 
the physical view is documented in hardware and software architectures that define specific 
instantiations at various nodes within the InfoSphere. This concept makes it easier to deal with 
such issues as the use of information exchange protocols as the primary means to achieve 
interoperability and the proper role of the DII COE in helping to establish a suitable platform 
foundation. We first discuss some aspects of the execution platform and then address an 
approach to assembling the JBI as a system, or confederation, of systems 

8.5.1 Platform Architecture 

8.5.1.1 A Role for a Standardized Execution Platform 

An infrastructure defined by the DII COE model may well be a useful tool in the C system 
developer’s kit bag. For reference, Figure 8-5 is the standard DII COE model showing the 
elements of the environment. Continued DII COE use will be more viable if DISA implements 
improvements to their DII COE strategy as briefed to the study team. Important steps would be 
to (1) move to completely COTS kernels, and (2) allow commercial procedures (sometimes 
called “logo certification” since this allows a vendor to put the appropriate logo on a product) to 
be used to satisfy at least Level 5 compliance certification. 49 A system developer who finds such 
a platform a good match to requirements, a way to economize on development, and a way to get 
instant interoperability in an information space might well elect to adopt it. These are just the 
sort of benefits the current DII COE aims to deliver. The point is that this would be simply an 
option for instantiation of the platform architecture, not the central strategy. 


49 DII COE compliance below Level 5 is not operationally meaningful. 
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Figure 8-5. Taxonomy of the Dll COE 


The primary route to interoperability remains the information services model and the exchange 
of messages through the publish/subscribe interfaces of the JBI. JBI services will be provided in 
a CSE, with each service specified by its interface, including metadata and other format 
specifications of information, procedures and constraints for invoking the service, and any other 
required elements. The CSE might well be implemented on DII COE-compliant platforms 
whose details are transparent to JBI users, following the concept of decoupling of the physical 
and logical views. In terms of the DoD C 4 ISR Architecture Framework, the DII COE is an 
important element of the Technical Architecture while the CSE is a major part of the System 
Architecture and mechanizes user requirements from the Operational Architecture. 

8.5.1.2 Thin Client Networks 

The history of multiuser information systems, exemplified in C 2 systems like TBMCS, is one of 
linking user workstations 50 on a local area network in a client-server environment. In a client- 
server environment, servers are used to store and manage files, provide a gateway for e-mail and 
file exchanges, monitor and fine tune network performance, and perform other system 
administration chores such as managing user accounts and controlling access privileges. The 
primary applications reside on the workstations, although to save license fees an organization 
may purchase a limited number of “seats” and control the number of copies of a program that are 
downloaded at one time for use on workstations. 


50 Workstation is used here in its generic sense, not just to mean a high end processor used for functions such as 
computer-aided design. 


8-21 


















































































































































































































































There is a widespread trend in information systems generally to centralize network functionality 
on powerful servers and to transform workstations into access devices which implement tailored 
interfaces to network services for individual users. The idea is usually called a “thin client.” 

This could be seen as a throwback to the early days of networks when “dumb” terminals logged 
on to a mainframe that did all the computing and storage. It can also be criticized on the grounds 
that it makes an organization even more vulnerable than it is already to server crashes, network 
outages, and other single point failures. However, the thin client approach has powerful 
advantages. Maintaining consistency of shared data, common configuration of shared 
applications, common and fully enforced access controls and intrusion defenses, and other 
system-wide features is easier. A thin client network can be simpler to certify for classified 
processing since workstations now have fewer capabilities to support malicious behavior like 
communications outside the firewall. In general, the information technology community seems 
to be moving in this direction, and many military systems are exploring the feasibility and 
benefits of the thin client concept. 51 

Clearly, the thin client model pertains in large measure to a logical view since it deals with how 
services are provided to users. However, it also has major physical implications since it drives 
such things as the nature of the platform employed by a given user, the capacity of the 
client/server network, and the choice of security mechanisms. 

Shared information services are at the heart of the JBI concept, and thus a network of powerful 
servers and thin clients looks like a good fit. However, care in implementation is essential. A 
fighter must still be able to perform its mission even if disconnected from the JBI by 
communications failures or hostile countermeasures. Mission planners, weaponeers, and 
intelligence analysts must be able to work through outages in the networks and server farms of 
an air operations center (AOC). Careful system engineering is required to map functionality 
onto servers, workstations, weapon systems, and all the other nodes of the platform environment 
and to ensure robustness under real world conditions. 

8.5.1.3 Network Computing 

With the concept of thin clients comes that of network computing. Related terms are web- 
enabled applications and data bases and application service providers. In each case, the idea is 
that a server makes data, applications, libraries and any other services required by a user to 
perform a function available over a network. Web-enabled data bases using XML have rapidly 
become the dominant technique for information sharing in such areas as business-to-business 
commerce. Web-enabled applications promise to make greater functionality available to users. 
The economic argument is that license or use fees will be smaller than the outright purchase cost 
of software. A relatively small set of standards associated with the basic Internet model, together 
with a shared programming language, are the basic enablers of the concept. 

The primary implementation of web computing today uses Java, developed by Sun 
Microsystems. Java is a programming language, but more importantly, it is a client-server 
paradigm in which a virtual machine is created on a user workstation which then executes 
applications from the server. Since the virtual machine is (in principle) identical regardless of 
the computer or operating environment that hosts it, Java applications are (in principle) 
universally sharable. There are issues with execution speed in real time applications because the 

51 The study team saw an example in use aboard the 3 rd Fleet command ship, USS Coronado. 
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normal Java mode is interpreted, vs. compiled, meaning that the workstation must do multiple 
calculations for each executed instruction, but these may be overcome with time. Java is widely 
taught in schools and shows signs of becoming the primary programming environment, 
especially since it has features that overcome limitations of earlier languages like C++. It is 
therefore possible that network computing using Java will be a major feature of the JBI platform 
environment. 

8. 5. 1.4 Component-Based Architecture 

A promising approach to the integration of a platform from a variety of products is the notion of 
treating software elements as components with fully defined interfaces that can be plugged into 
an operating environment. This can, in fact, take the form of defining metadata about a 
component. By encapsulating the functionality a component delivers and allowing access to the 
services it provides only through this well-defined interface, conflicts with other components can 
be minimized and the process of invoking component services through an interface can be 
simplified. 

8.5.1.5 Communications 

The essence of the JBI is the exchange of information within the InfoSphere and among users. 
This depends on robust, timely data communications through a set of links and networks that 
form a common communications environment. This is therefore a critical element of the JBI 
platform environment. One of the key functions of the JBI is to manage the connection fabric 
and the traffic on it so as to best satisfy the service requirements of users. 

Two important concepts here are “spontaneous” or “plug-and-work” network configuration and 
self annealing networks. The first of these means that an eligible user can join a network simply 
by connecting to it; practical details such as address assignment are automated. In the Jini 
construct, developed by Sun as the networking complement to Java, a service wishing to join a 
network registers with a “federation” through a “lookup service,” and clients find these enrolled 
services by Java type from the lookup service. The associated code then moves to the client 
from the lookup service like any network application. In a self annealing network, service is 
maintained or restored after failures or hostile action by a network control function which 
establishes links and routes traffic based on a set of rules and the available communications 
paths. In any case, it is essential that the nodes of the infosphere and its users be connected by 
high capacity, redundant, and dynamically managed communications channels with the 
responsiveness, security and fault tolerance to maintain services under the stress of operations. 

8.5.2 A Migration Path to the JBI 

The physical structure of the JBI can be represented as an assembly of mission-relevant systems, 
which become the components, together with enabling information management services, all 
passing information to and from one another. Figure 8-6 illustrates a primitive example of a JBI. 
The small dark outlined ovals, around the periphery of the communications mechanism, called 
the “Global Information Grid,” 52 represent command and control entities. These software¬ 
intensive systems provide a variety of services to users, according to the requirements of the 
organizations that bought or built them. C 2 systems and supported users and platforms will often 


52 As currently defined by DoD, the GIG is a complete information infrastructure similar in some ways to the JBI, 
but the communications layer of that infrastructure is what is of interest here. 
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need to exchange information with each other in order to perform their functions. Such message 
exchanges have traditionally been accomplished over dedicated circuits or via some form of 
network that could handle the individual point-to-point information transfers. The GIG 
encompasses a variety of communications paths, including the Non-Secure Internet Protocol 
Router Network, Secret Internet Protocol Router Network, and JWICS networks that provide the 
primary connection fabric of the GCCS. 



Figure 8-6. A Top-Level Concept of the JBI as a Collection of Systems and Services Interacting via the 

Global Information Grid 


For the JBI, these information transfers are augmented by having the individual systems expose 
(publish) their information in a manner that is interpretable by the other JBI participants. If a 
system conforms to the protocols that enable information to be interpreted in the JBI, then that 
system is a JBI client. In addition, since it is essential that the JBI facilitate the migration of 
legacy systems to the new structure, message exchanges are allowed through a variety of paths. 
The normal connectivity is via the shared GIG “cloud.” However, messages can also be 
exchanged through “private” channels when performance, security, or other considerations so 
dictate. Similarly, legacy system-to-system connections may persist when this helps with the 
assembly and functioning of the JBI. In contrast to the logical view in Figure 8-4, where users 
are at the top of the hierarchy and the information repository forms the foundation, the physical 
view in Figure 8-6 emphasizes that users, systems, and the nodes that provide information 
storage and processing can all be thought of as peers since each is a client of the JBI interacting 
via the shared network. 

The light colored ovals without outlines represent services or “middleware” that enable the JBI 
to function efficiently and effectively. The individual JBI clients are made aware of one another 
via one of the JBI enabling facilities that serves as a “broker.” An individual JBI client will 
“publish” information that it anticipates will be useful to other JBI clients. The published 
information might be raw information, access to an information storage area, or the 
announcement of a service that the JBI client can offer to other JBI participants. An individual 
JBI client will also present a “subscription” or “query” for information that it hopes to glean 
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from the JBI. The broker’s task is to match the publishments with the subscriptions and to 
inform both parties of their mutual existence. 

Although similar in concept to search engines used on the Internet, the JBI broker is a bit more 
sophisticated because it will make the pairwise associations of publishments and subscriptions 
with some oversight. The oversight may encompass rules for the management of information, 
for example, command policies. These policy rules may prohibit certain publish/subscribe 
matches and require others; they may also adjudicate preferential connections for yet others. In 
other words, the broker provides its services according to policy directives and rules that may be 
changed from time to time to conform to the commander’s intent. 

The JBI broker also has some other capabilities. It may prioritize the pairwise matches. These 
priorities might be established by the commander, but they may also be established through 
default conditions. Based on the information content to be exchanged over the JBI, the broker 
may identify some transactions as higher priority than others, and it may provide that priority 
hierarchy to the communications systems. In this way, the communications can deliver quality 
of service that matches the specific information content that is flowing throughout the enterprise. 
As the JBI evolves and technology matures, brokers will become ever more competent, adding 
services like discovery and fusion as were described in Section 8.4.2.9. 

Finally, as alluded throughout the logical description of the JBI, other information management 
services are incorporated in the JBI. These services, also represented by light ovals in the 
Figure 8-6, may be introduced to the system by merely incorporating them in the infosphere as 
additional clients. Services such as data mediation (implied as a capability to achieve the 
Structured Common Representation), security policy services, temporary or persistent data 
storage for mission relevant capabilities that are “information storage impaired,” portals for 
preparing special user-relevant information views of the infosphere, etc. may all be services that 
can be added to the JBI as the level of sophistication desired escalates. 

The effect of all this is that each participant or client o the JBI sees the InfoSphere through a 
portal that mechanizes the particular interactions that client requires. These portals are 
somewhat analogous to personal web pages, and they implement the tailored services interface 
appropriate to a specific JBI participant. They combine the publish and subscribe actions 
defined by user-established criteria with actions that respond to central policy, such as “push” of 
command-dictated messages. They incorporate a mapping of the InfoSphere to make the 
fetching and storage of information as efficient as possible. As brokers and other JBI functions 
mature, portals offer users the growing range of services described above. 

An important physical attribute of the JBI is the ability to introduce new capability with minimal 
impact on existing systems. With current system structure, new capability often requires an 
invasion into the structure of an existing system and disassembly of functions and information so 
that the new capability can be introduced. With the JBI, as new technology and new 
communications mechanisms surface, the novel capabilities can subscribe to the legacy 
information repository and provide new information objects by merely publishing into the JBI. 
Acceptance and exploitation of the new information will take place through the natural 
publish/subscribe mechanisms described earlier. The ability of the JBI to scale is assured by 
keeping the physical interfaces simple, by decoupling dependencies upon critical elements, and 
by preserving anonymity among participants. 
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In Figure 8-4, we suggested that the information content of the JBI would be logically organized 
in domains, with provisions for mapping the content of various data bases into an SCR. An 
analogous concept applies here in considering the physical structure of the InfoSphere. The 
various JBI clients are likely to elements of particular functional domains, each contributing data 
and information, and each responsible for control and management within its boundaries, subject 
to the overall rules or policies governing the JBI as a whole. 

Each JBI participant, or node, in Figure 8-6 could be implemented as an individual system using 
a layered architecture in which the applications comprising the node’s functionality ride on a 
node platform. The platform might well be defined by a version of the DII COE, facilitating the 
task of integrating applications within the node. Such an implementation will be assisted if 
DISA follows through on plans to move the lower levels of the DII COE to purely commercial 
products and to provide for technology obsolescence mitigation and long-term backward 
compatibility. The larger scale of interoperability is accounted for by information exchanges 
through the GIG or over other links and networks, using an Intemet-like set of protocols and 
supporting standards for publish and subscribe. Techniques described earlier in this chapter, 
including XML wrappers for legacy data bases and web-enabling applications will be central to 
this implementation strategy. 

8.6 A JBI Strategy 

There remains the question of choosing and executing the concrete, feasible actions that will 
power the migration from the current C 2 environment to the JBI. The following steps might 
form the basis for such a strategy: 

• Sponsor, Define, and Lead an Evolutionary Process. There are too many unknowns today to 
define the JBI information model and services in detail. Indeed, as noted above, there is no final 
model, because the warfighting environment itself is in constant flux. Therefore, what’s needed 
is to involve the key stakeholders in a process of exploring alternatives, gathering data and 
experience, evaluating technologies and products, choosing standards, and incrementally building 
and demonstrating the JBI. The success of the Internet is largely based on the fact that its 
standards emerged from the consensus of communities of interest, and a process like that of the 
W3C or the more broadly based IETF may be very useful. The Air Force can and should take 
this on, working with the Joint Staff, Office of the Assistant Secretary of Defense: Command, 
Control, Communications, and Intelligence (OASD/C 3 I), (DISA), the other Services, DARPA, 
and industry/academia. This is the overarching activity, of which the remaining actions are 
components. 

• Refine the JBI Information Model. The views and conclusions expressed in this discussion 
need to be rigorously challenged, vetted or corrected, and refined through the efforts of experts in 
the field and through analyses and demonstrations of C 2 systems. The right information model 
attributes, the right set of implementing standards, the right information assurance model, and the 
right way of presenting information services to C 2 users and applications are key questions 
needing thorough investigation, including in operational exercises like the Joint Expeditionary 
Force Experiment. A key issue is the need to develop a method whereby the system can associate 
a unique identifier with an information object and then find out such properties as the object’s 
location, type, and access control permissions. 

• Migrate Legacy Systems Toward the Model. Existing systems intended for continued use 
should be progressively modified toward compliance with the JBI information model as fast as 
resources will permit. The goal is to enable these systems as JBI clients. The first steps are to 
develop XML tags for the data bases or other wrappers that allow legacy data structures to 
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interoperate in the JBI model, and to web-enable the applications. The other attributes of the 
model can be progressively implemented as the model matures. 

• Migrate the DII COE. The Air Force does not “own” the DII COE but can and should be a 
leading voice for the agenda of migrating toward a services-based model, with standards focused 
on services rather than products. This will probably entail both constructive engagement with 
DISA (starting with agreement at the Joint Staff and OASD/C 3 I) and the other Services and 
agencies involved, and work within the Air Force to develop the JBI information model and 
demonstrate its advantages. A central element of this is to move away from the current DII COE 
paradigm of exhaustive standardization of platform details and toward an Internet-like strategy. 
The distributed C 4 ISR simulation network that is discussed in Chapter 11 of this report, along 
with applicable Advanced Concept Technology Demonstrations (ACTDs), actions associated with the 
“AOC as a weapon system” initiative, updates to legacy systems, and other related efforts should 
be coordinated to make rapid progress toward this goal. The basic idea is to complement the 
DII COE platform standardization strategy with the logical model of JBI services and to evolve 
DII COE toward being an effective JBI platform option 

• Use the Adaptive Battlespace Awareness ACTD as a Vehicle. The current focus of the ACTD 
on the Common Operating Picture is appropriate, and any expansion of the ACTD definition to 
address the JBI information model and produce the evidence to support migrating the DII COE 
should be straightforward. As the proposed Experimental AOC at Langley Air Force Base (AFB) 
takes on the role of TBMCS test bed, it should be a participant and might be the logical host site 
for the ACTD. Other facilities such as the C 2 Training and Innovation Center at Hurlburt AFB and 
the C 2 Unified Battlespace Environment at Hansom AFB could, over time, be integrated via 
broadband links into the distributed C 4 ISR network to enrich the participation and the resources 
available to execute the ACTD. 

• Cooperate with DARPA. The Air Force should exploit technologies from DARPA programs and 
partner with DARPA to speed the transition of these into JBI implementation. Among other 
things, this could provide access to the larger IT community and opportunities to influence the 
content of emerging standards so that they best address military C 2 needs. 

8.7 Summary 

The future of Air Force C 2 , as well as the best hope of achieving the goals of Joint Vision 2020 
and Vision 2020, rest with the JBI. The complexity of this information system is unprecedented, 
but the technical means to build the InfoSphere are rapidly emerging. The greater problems are 
likely to be political—reaching a consensus within the Air Force and then across DoD on the 
“business model” and subordinating individual agendas and spheres of control to the greater 
good. The JBI will come about through a steady evolutionary process of defining and refining 
the information model, incrementally adding systems and functionality, validating the design in 
exercises and operations, and institutionalizing the principles and practices of information- 
enabled warfare. There can be few more critical tasks facing the Air Force in the years ahead. 
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Chapter 9 
Summary 


9.1 Introduction 

There is no doubt in the minds of the Air Force Scientific Advisory Board (SAB) that the Air 
Force leaders recognize the importance of the effective command and control (C 2 ) of its forces in 
achieving success in air operations. There is also a profound recognition that leadership is 
understanding that air forces engaged in past conflicts have not benefited from the awesome 
power of an effective theater C 2 system with the flexibility and responsiveness necessary in the 
dynamic battlespace which technology has brought. 

Implementing the necessary changes to the current Theater Air Command and Control System 
(TACCS) involves much more than a technical (hardware and software) change. In fact, it 
requires a fundamental change in “business practices”, to borrow a commercial term. It requires 
a top-down revision in thinking and in accomplishing, before any technical changes are made. 

9.2 Leadership Commitment 

During the course of the Study, the team reviewed the history of deficiencies and fixes to the 
TACCS. There have been numerous studies, including four SAB Studies in the last five years. 
There have been organizations and re-organizations, all with little lasting impact on the state of 
the capabilities. 

A fundamental element of the solution must be a commitment on the part of leadership, a 
commitment to not only initiate actions in supporting the business practice change, but to lay in 
place a mechanism for high-level review and follow-up to assure actions are fully completed, 
and that the resulting command and control system allows for evolution as the technology 
advancements, operational concepts, and world environment dictate. 

We are encouraged at the dedication of the current leadership—General Michael Ryan, Chief of 
Staff, U.S. Air Force; General John Jumper, Commander, Air Combat Command (ACC); and 
Major General Gerald Perryman—in recognizing the need for action, as well as both the 
technical and operational issues associated with command and control and the information 
technology field. Continued attention is encouraged. 

9.3 Organizational Change 

The management of C 2 has traditionally been spread across combat and support mission areas, 
boards/panels, and the associated organizational structure without considering the essential need 
for a C 2 system integrated across the Air Force. Only since the Air Command and Control 
Agency (AC 2 A), now the Aerospace Command and Control, Intelligence, Surveillance, and 
Reconnaissance Center (AC2ISRC), was established in 1997 has there been any serious 
consideration of the need to concentrate effort in the area. The AC2ISRC has clearly had great 
impact on the command and control function, finally getting its arms around the myriad of 
concept of operations, architectures, programs, program elements, and people. 
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At the Air Staff level, however, there remains a fragmentation of management of command, 
control, communications, intelligence, surveillance, and reconnaissance across 8 Panels, 131 
program elements, and 4 major two-letter directorates. Moreover, as important as the Center is 
to the Commander of ACC as well as other major commands, it cannot be effective without a 
similar consolidation of management at the Air Staff. 

Consolidation of the management of C 2 is essential. We cannot expect that the proper 
management trades critical to a constrained budget will be made in a organizational structure in 
which management responsibilities are fragmented. 

9.4 Defining Command and Control 

The official definition of command and control is: 

“Command and control is the exercise of authority and direction by a properly designated 
commander over assigned and attached forces in the accomplishment of the mission. Command 
and control functions are performed through an arrangement ofpersonnel, equipment, 
communications, facilities, and procedures employed by a commander in planning, directing, 
coordinating, and controlling forces and operations in the accomplishment of the mission. ” 
(Source: Joint Publication 1-02, Department of Defense Dictionary of Military and Associated 
Terms) 

So, while command and control is a function, the many hardware and non-hardware elements 
that enable the function must be considered in the management and modernization process. 

9.5 Applying Resources 

The Air Force faces a critical shortage of funds for operations and maintenance (3400), for 
system development (3600), and for acquisition (3080). It is not likely that there will be 
significant relief in the foreseeable future. Thus, the Air Force must assume a level budget, and 
carefully allocate the funding available to get the most from each dollar. We submit that the 
current process involving many program elements and no single Panel to represent such 
activities as the AC2ISRC to assure consideration of the alternatives as well as to prioritize the 
initiatives, is not an appropriate way to manage limited funds. 

Thus, we suggest a greatly reduced number of program elements, and a C 3 Panel in the Board 
Structure as the surest way to success in solving the many command and control problems. 

9.6 Summary 

The Air Force Scientific Advisory Board recognizes the substantial pressures on the Air Force to 
do more with fewer resources. Most certainly, the effective use of command and control in the 
management and control of air operations could improve the efficiency of the combat forces. 

The recommendations included in this report are the collective opinion of the study team. 
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BACKGROUND: The Air Force needs to define its command and control (C ) system in light 
of recent points of experience in Operations Desert Shield/Desert Storm and Operation Noble 
Anvil in Kosovo, taking advantage of technological improvements. The Air Force is not on a 
path today that provides coherence across space, air, and land assets to support the most timely 
and effective decision making and execution. The USAF Scientific Advisory Board (SAB) and 
other defense advisory boards have conducted a number of studies over the past decade that bear 
directly on this problem and form a foundation from which to work. The Board is now being 
asked to assess the C 2 system and the supporting communication and information systems, to 
consider technical and process improvements, and to make recommendations on what should be 
done to “have the USAF linked by 2005” and to build toward the Air Force’s long term 
command and control goals. 

Study Products: Briefing to SAF/OS & AF/CC in October 2000. Publish report in 
December 2000. 

Charter: 

6. Define the Air Force command and control system with today’s capabilities and identify alternatives 
to enhance it over time: 

• Describe operational C 2 concepts and procedures. 

• Examine functional tasks and consider where these tasks should be accomplished in the 
organizational construct. 

• Determine connectivity/network requirements for the defined system and improved systems, and 
identify where today’s systems are out of phase or disconnected. 

• Include the integration of intelligence, surveillance and reconnaissance (ISR) assets. 

7. Define interoperability (joint and coalition) to ensure coordinated efforts on the battlefield. 

8. Identify the technologies that can enhance present and future command and control systems, 
with near term emphasis on timely and effective communication. 

9. Assess the acquisition, programmatic and cost effectiveness issues. 

10. Consider the organizational, personnel, training and support consequences. 

11. The report should include recommendations on: 

• Defining a specific command and control system with today’s assets. 

• Changes in the system possible in the near term with new procedures and technology, with 
emphasis on “having the USAF linked by 2005”. 

• Longer-term improvements consistent with the Air Force’s long-term vision for command and 
control. 
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AADC 

ABCCC 

ABCS 

ABIT 

AC 2 A 

AC2ISRC 

ACC 

ACO 

ACS 

ACTD 

ADOCS 

AEF 

AESA 

AF/DP 

AF/IL 

AF/SC 

AF/TE 

AF/XO 

AF/XOC 

AF/XOI 

AF/XOJ 

AF/XOR 

AF/XP 

AF/XPP 

AFATDS 

AFB 

AFDD 

AFFOR 

AFI 

AFMC 

AFOSR 

AFOTEC 

AFRF 

AFRF/IF 

AFSC 

AFSOC 

AFSPACE 

AFSPACECOM 

AMC 

AMD 

AMDWS 

AMOCC 

AMPS 

AO 

AOC 

API 

AR 

ASAS 
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Area Air Defense Commander 

Airborne Battlefield Command and Control Center 

Army Battle Control System 

Airborne Information Transfer 

Air Command and Control Agency 

Aerospace Command and Control, Intelligence, Surveillance, and 
Reconnaissance Center 
Air Component Commander 
Airspace Control Order 
Agile Combat Support 

Advanced Concept Technology Demonstration 
Automated Deep Operations Coordination System 
Aerospace Expeditionary Force 
Active Electronic Scanned Arrays 
Deputy Chief of Staff, Personnel 
Deputy Chief of Staff, Installations and Fogistics 
Deputy Chief of Staff, Air and Space Operations 
Headquarters Air Force, Test and Evaluation 
Deputy Chief of Staff, Air and Space Operations 
Deputy Chief of Staff, Air and Space Operations, Command and 
Control 

Deputy Chief of Staff, Air and Space Operations, Intelligence, 
Surveillance, and Reconnaissance 
Deputy Chief of Staff, Air and Space Operations, Joint Matters 
Deputy Chief of Staff, Air and Space Operations, Operational 
Requirements 

Deputy Chief of Staff, Plans and Programs 

Deputy Chief of Staff, Plans and Programs, Programs 

Advanced Field Artillery Tactical Data System 

Air Force Base 

Air Force Doctrine Document 

Air Force Forces 

Air Force Instruction 

Air Force Materiel Command 

Air Force Office of Scientific Research 

Air Force Operational Test and Evaluation Center 

Air Force Research Faboratory 

Air Force Research Faboratory, Information Directorate 

Air Force Systems Command 

Air Force Special Operations Command 

Air Force Space Command 

Air Force Space Command 

Air Mobility Command 

Air Mobility Division 

Air Missile Defense Work Station 

Air Mobility Operations Control Center 

Air Mission Planning System 

Area of Operations 

Air Operations Center 

Application Program Interface 

Acquisition Reform 

Army’s All Source Analysis System 
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ASC 

ASOC 

ASR 

ATACMS 

ATAF 

ATARS 

ATDL-1 

ATO 

AWACS 

BCC 

BCD 

BCS 

BGPHES 

C 2 

C 2 IPS 

C 2 ISR 

c 2 tig 

c 2 wac 

C 3 

^ 4 t 


c 4 isp 

c 4 isr 

C/S/A 

C/JFACC 

CADM 

CAF 

CAIV 

CAOC 

CAS 

CC 

CCE 

CCO 

CCPDS-R 

CDE 

CDL 

CEC 

CFACC 

CHBDL 

CINC 

CIO 

CIS 

CJCSI 

CMM 

CoABS 

COD 

COE 

COMAFFOR 

COMAFSPACE 

COMPES 

CONOPS 

CONUS 


Aeronautics Systems Center 
Air Support Operations Center 
Automated Speech Recognition 
Tactical Missile System 
Allied Tactical Air Forces 

Advanced Tactical Airborne Reconnaissance System 
Army Tactical Data Link-1 
Air Tasking Order 

Airborne Warning and Control System 
Battle Control Center 
Battlefield Coordination Detachment 
Battle Control System 

Battle Group Passive Horizon Extension System 
Command and Control 

Command and Control Information Processing System 
Command, Control, Intelligence, Surveillance, and Reconnaissance 
Command and Control Training and Innovation Center 
Command and Control Warrior Advanced Course 
Command, Control, and Communication 
Command, Control, Communications, and Intelligence 
Command, Control, Communications, and Computers 
Command, Control, Communications, Computers, and Intelligence 
Command, Control, Communications, Computers, and Intelligence 
Support Plan 

Command, Control, Communications, Computers, Intelligence, 
Surveillance, and Reconnaissance 
Commander in Chiefs, Services and Agencies 
Combined/Joint Force Air Component Commander 
Core Architecture Data Model 
Combat Air Force 
Cost as an Independent Variable 
Combined Aerospace Operations Center 
Close Air Support 
Commander 

Common Communications Environment 
Chief, Combat Operations 

Command Center Processing and Display System-Replacement 

Common Data Environment 

Common Data Link 

Cooperative Engagement Capability 

Combined Forces Air Component Commander 

Common High-Bandwidth Data Link 

Commander in Chief 

Chief Information Officer 

Combat Intelligence System 

Chairman of the Joint Chiefs of Staff Instruction 

Capability Maturity Model 

Control of Agent Based Systems 

Combat Operations Division 

Common Operating Environment 

Air Forces Commander 

Commander Air Force Space Command 

Contingency Operations Mobility Planning and Execution System 
Concept of Operations 
Continental United States 
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COP 

COTS 

CRC 

CRD 

CRE 

CSAF 

CSAR 

CSE 

CSP 

CSS1 

CSS2 

CT 

CTAPS 

CUBE 

DAC 

DAML 

DARPA 

DASC 

DASR 

DCAPES 

DCGS 

DCO 

DCS 

DDDS 

DEP 

DFAD 

DIA 

DII 

DII COE 
DIRMobFor 
DISA 
DMB 

DMPI 

DMRE 

DMS 

DMT 

DOCC 

DoD 

DoDD 

DODIIS 

DP&E 

DT 

DT&E 

DTD 

EA 

EA/SD 

EAF 

ECM 

EO 

EOC 

EPLRS 

ESC 

EUCOM 

FAAD 

FAC-A 


Common Operating Picture 
Commercial-Off-the-Shelf 
Control and Reporting Center 
Capstone Requirements Document 
Control and Reporting Element 
Chief of Staff, United States Air Force 
Combat Search and Rescue 
Common Services Environment 
Communications Support Processor 
Common Sensor System One 
Common Sensor System Two 
Continuation Training 

Contingency Theater Automated Planning System 

Command and Control Unified Battlespace Environment 

Designated Acquisition Commander 

DARPA Agent Markup Language 

Defense Advanced Research Projects Agency 

Direct Air Support Center 

Direct Air to Satellite Relay 

Deliberate Contingency Action Planning and Execution System 

Distributed Common Ground System 

Director of Combat Operations 

Deputy Chief of Staff 

Defense Data Dictionary System 

Distributed Engineering Plant 

Digital Feature Analysis Data 

Defense Intelligence Agency 

Defense Information Infrastructure 

Defense Information Infrastructure Common Operating Environment 

Director Mobility Forces 

Defense Information Systems Agency 

Department of Defense Intelligence Information System Management 
Board 

Desired Mean Point of Impact 

Dynamic Mission Readiness Environment 

Defense Message System 

Distributed Mission Training 

Deep Operations Coordination Cell 

Department of Defense 

Department of Defense Directive 

Department of Defense Intelligence Information System 

Dynamic Planning and Execution 

Development Test 

Development Test and Evaluation 

Document Type Definition 

Evolutionary Acquisition 

Evolutionary Acquisition/Spiral Development 

Expeditionary Air Force 

Electronic Countermeasures 

Electro-Optical 

Enroute Operations Center 

Enhanced Position Location Reporting System 

Electronic Systems Center 

European Command 

Forward Area Air Defense Data Link 

Forward Air Control-Airborne 


Appendix B-3 



FDL 

Forward Area Air Defense Data Link 

FIOP 

Family of Integrated Operational Pictures 

FLEX 

Force Level Execution 

FLOT 

Forward Line of Own Troops 

FOA 

Field Operating Agency 

FOPEN 

Foliage Penetration 

GBDL 

Ground Based Data Link 

GCCS 

Global Command and Control System 

GCCS-A 

Global Command and Control System-Army 

GCCS-AF 

Global Command and Control System-Air Force 

GCCS-M 

Global Command and Control System-Maritime 

GCSS-AF 

Global Combat Support System-Air Force 

GDSS 

Global Deployment Support System 

GIG 

Global Information Grid 

GMTI 

Ground Moving-Target Indication 

GOTS 

Government-Off-the-Shelf 

HQ 

Headquarters 

HRR 

High Range Resolution 

HSI 

Human-System Interface 

HTML 

Hypertext Markup Language 

I&I 

Integration and Interoperability 

I&RTS 

Integration and Run Time Specification 

IA 

Information Assurance 

IBS 

Integrated Broadcast Service 

ICD 

Interface Control Document 

IDL 

Interoperable Data Link 

IDM 

Information Dissemination Management 

IER 

Information Exchange Requirement 

IETF 

Internet Engineering Task Force 

IJMS 

Interim JTIDS Message Specification 

IKIWISI 

I’ll Know It When I See It 

IM 

Information Management 

IMS 

Information Management System 

10 

Information Operations 

IOC 

Initial Operating Capability 

IOP 

The Interoperability Panel 

IP 

Internet Protocol 

IPB 

Intelligence Preparation of the Battlefield 

IPT 

Integrated Product Team 

IQT 

Initial Qualification Training 

IR 

Infrared 

ISC 2 

Integrated Space Command and Control 

ISR 

Intelligence, Surveillance, and Reconnaissance 

ISSE 

Information Support Server Environment 

IT 

Information Technology 

IT-21 

Information Technology-21 

IVIS 

Intra Vehicular Info System 

IW 

Information Warfare 

IWC 

Information Warfare Center 

J/CAOC 

Joint/Combined Aerospace Operations Center 

J/CFACC 

Joint/Combined Force Air Component Commander 

JAC 2 C 

Joint Aerospace Command and Control Course 

JACAC 

Joint Aerospace Computer Applications Course 

JAOC 

Joint Aerospace Operations Center 

JASAC 

Joint Aerospace Systems Administrator Course 

JBI 

Joint Battlespace InfoSphere 
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JCSAR 

Joint Combat Search and Rescue 

JCTN 

Joint Composite Tracking Network 

JDEP 

Joint Distributed Engineering Plant 

JDN 

Joint Data Network 

JEFX 

Joint Expeditionary Force Experiment 

JFACC 

Joint Forces Air Component Commander 

JFC 

Joint Forces Commander 

JGAT 

Joint Guidance Apportionment & Targeting 

JIEO 

Joint Information Engineering Organization 

JITC 

Joint Interoperability Test Center 

JITF 

Joint Integration and Test Facility 

JMA 

Joint Mission Architectures 

JMPS 

Joint Mission Planning System 

JOA 

Joint Operational Architecture 

JointSTARS 

Joint Surveillance Target Attack Radar System 

JOTS 

Joint Operational Tactical System 

JP 

Joint Publication 

JPN 

Joint Planning Network 

JPO 

Joint Program Office 

JSA 

Joint System Architecture 

JSF 

Joint Strike Fighter 

JSRC 

Joint Search and Rescue Center 

JSSC 

Joint Air Operations Senior Staff Course 

JTA 

Joint Technical Architecture 

JTF 

Joint Task Force 

JTDFMP 

Joint Tactical Data Fink Management Plan 

JTIDS 

Joint Tactical Information Distribution System 

JTRS 

Joint Tactical Radio System 

JV2010 

Joint Vision 2010 

JV2020 

Joint Vision 2020 

KPP 

Key Performance Parameter 

FCA 

Fife Cycle Architecture 

FD/HD 

Fow Density/High Demand 

EMMS 

Fockheed Martin Mission Systems 

FOCIS 

Fogistics Control and Information Support 

EOS 

Fine of Sight 

FRP 

Fimited Response Package 

FWCDF 

Fightweight Common Data Fink 

MAJCOM 

Major Command 

MAP 

Mission Area Plan 

MASC 

Modeling, Analysis, and Simulation Center 

MCS 

Maneuver Control System 

MDA 

Milestone Decision Authority 

MECDF 

Mission Equipment Control Data link 

METE 

Mission-Essential Task Fist 

METOC 

Meteorology and Oceanography 

MIDB 

Military Integrated Data Base 

MIDS 

Multifunction Information Distribution System 

MFS 

Multilevel Security 

MRDF 

Multi-Role Data Fink 

MQT 

Mission Qualification Training 

MS&A 

Modeling, Simulation, and Analysis 

MTE 

Moving-Target Exploitation 

MTS 

Marine Tactical System 

MX 

Military Experimental 

N/UWSS 

NORAD/USPACECOM Warfighting Support System 
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NAF 

Numbered Air Force 

NATO 

North Atlantic Treaty Organization 

NGO 

Non-Government Organizations 

NIMA 

National Imagery and Mapping Agency 

NMCC 

National Military Command Center 

NORAD 

North American Air Defense Command 

NRO 

National Reconnaissance Office 

NS A 

National Security Agency 

O&M 

Operations and Maintenance 

OASD/C 3 I 

Office of the Assistant Secretary of Defense: Command, Control, 
Communications, and Intelligence 

OPS 

Operations 

ORD 

Operational Requirements Documents 

OSC 

Operational Support Center 

OSD 

Office of the Secretary of Defense 

OT 

Operational Test 

OT&E 

Operational Test and Evaluation 

OTA 

Operational Test Agency 

OTS 

Officer Training School 

PACOM 

Pacific Command 

PADIL 

Patriot Automated Digital Information Link 

PE 

Program Element 

PEO 

Program Executive Officer 

PLRS 

Position Location Reporting System 

PM 

Program Manager 

PMD 

Program Management Directive 

PME 

Professional Military Education 

POM 

Program Objective Memorandum 

POSIX 

Portable Operating System for Information Exchange 

QRP 

Quick Response Package 

R&D 

Research and Development 

RF 

Radio Frequency 

ROE 

Rules of Engagement 

ROTC 

Reserve Officer Training Corps 

RTIP 

Radar Technology Improvement Program 

S/GA 

Situation and Global Awareness 

S&T 

Science and Technology 

SAB 

Air Force Scientific Advisory Board 

SADL 

Situation Awareness Data Link 

SAE 

Service Acquisition Executive 

SAF 

Assistant Secretary of the Air Force 

SAF/AQ 

Assistant Secretary of the Air Force, Acquisition 

SAF/AQI 

Assistant Secretary of the Air Force, Information Dominance 

SAR 

Synthetic Aperture Radar 

SATCOM 

Satellite Communications 

SBIR 

Small Business Innovative Research 

SCDL 

Surveillance and Control Data Link 

SCR 

Structured Common Representation 

SD 

Spiral Development 

SDM 

Spiral Development Model 

SEAD 

Suppression of Enemy Air Defenses 

SEI 

Software Engineering Institute 

SHADE 

Shared Data Engineering 

SIGINT 

Signals Intelligence 

SIPRNET 

Secret Internet Protocol Router Network 

SODO 

Senior Offensive Duty Officer 
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SPAWAR 

U.S. Navy Space and Naval Warfare Systems Command 

SPINS 

Special Instructions 

SPO 

System Program Office 

SqKm 

Square Kilometer 

SQL 

Structured Query Language 

SWPS 

Strategic War Planning System 

T&E 

Test & Evaluation 

TACC 

Tanker Airlift Control Center 

TACCS 

Theater Aerospace Command and Control System 

TACCSF 

Theater Air Command and Control Support Facility 

TACFIRE 

Tactical Fire Direction System 

TACP 

Tactical Air Control Party 

TACS 

Theater Air Control System 

TADIL-J 

Tactical Digital Information Link J 

TAFIM 

Technical Architecture Framework for Information Management 

TAIS 

Tactical Air Information System 

TALCE 

Tanker Airlift Control Element 

TBMCS 

Theater Battle Management Core System 

TCP 

Transmission Control Protocol 

TCP/IP 

Transmission Control Protocol/Internet Protocol 

TCT 

Time-Critical Targeting 

TIE 

Technology Integration Experiment 

TPFDD 

Time Phased Force Deployment Data 

TRP 

Theater Response Package 

TSPR 

Total System Performance Responsibility 

TTPs 

Tactics, Training and Procedures 

TULIP 

Through Life Interoperability Planning 

UAV 

Unmanned Aerial Vehicle 

UGS 

Unattended Ground Sensors 

UHF 

Ultrahigh-F requency 

UHR++ 

Ultrahigh Resolution 

USAF 

United States Air Force 

use 

University of Southern California 

USCINCSPACE 

Commander in Chief United States Space Command 

USMTF 

U.S. Message Transmission Format 

USN 

United States Navy 

USSPACECOM 

United States Space Command 

USSTRATCOM 

U.S. Strategic Command 

UTC 

Unit Type Codes 

VMF 

Virtual Message Format 

VTC 

Video Teleconferencing 

W3C 

World Wide Web Consortium 

wees 

Wing Command and Control System 

woe 

Wing Operations Center 

XML 

Extendable Markup Language 


Appendix B-7 



(This Page Intentionally Left Blank) 


Appendix B-8 



Appendix C to Volume 2 
Study Organization 


Study Chairman 

Dr. Peter R. Worch 

Vice Study Chairman 

General James P. McCarthy, USAF (Ret) 

SAB Military Director 

Lt Gen Stephen B. Plummer 

General Officer Participant 

General John P. Jumper 

SAB Executive Director 

Col Gregory H. Bishop 

SAB Study Executive Officer 

Capt D. Brent Morris, AF/SB 

Panel Chairs 

Concept and System Definition Panel: Lt Gen Joseph Hurd, USAF (Ret) 
Interoperability Panel: Dr. John M. Borky 
Technology Panel: Dr. Alison K. Brown 

Acquisition and Program Management Panel: Maj Gen Eric Nelson, USAF (Ret) 
People and Organization Panel: Mr. Jeffery B. Erickson 
Vision and Bridging Concepts Panel: Mrs. Natalie W. Crawford 


Appendix C-l 



Concept and System Definition Panel 


Lt Gen Joseph E. Hurd, USAF (Ret), Chair 
Private Consultant 

Maj Gen John A. Corder, USAF (Ret) 

Private Consultant 

Mr. Troy Crites 
Sparta, Inc. 

Dr. Flewellyn S. Dougherty 
Director of Technology 
Raytheon Electronic Systems 

Mr. Jim Hale 
Private Consultant 

Maj Gen John Hawley, USAF (Ret) 

Private Consultant 

Mr. David Hess 

AC2ISRC 

MITRE 

Col Stu Kraft, USAF (Ret) 

Director, Business Development 

Northrop Grumman/Fogicon Technical Solutions 

Maj Robert Fanahan 

Branch Chief, Future Communications Systems 
National Reconnaissance Office 

Prof. Alexander H. Fevis 
Professor 

George Mason University 

Prof. Christine Mitchell 

Professor 

Georgia Tech 

Maj Robin Morris 
AC2ISRC/C2A 

Col Wayne Ranne 
AC2ISRC/C2X 

Col Mike Reavey, USAF (Ret) 

Private Consultant 


Appendix C-2 



Mr. Skip Saunders 
Executive Director 
MITRE 

Prof. Gene Spafford 
Professor 
Purdue University 

Col Carl Van Pelt, USAF (Ret) 

Private Consultant 

Lt Gen Ronald Watts, USA (Ret) 

President 

Leadership Development Services 

Executive Officer: Capt Larry W. Norman, Jr., AC2ISRC/C2RO 
Technical Writer: Maj Thomas Schorsch, USAFA 


Appendix C-3 



Interoperability Panel 


Dr. John M. Borky, Chair 

Chief Scientist 

Tamarac Technologies, LLC 

RADM John R. Batzler, USN (Ret) 

Senior Warfighting Analyst 
Center for Naval Analyses 

Prof Claude R. Canizares 
Director, Center for Space Research 
Massachusetts Institute of Technology 

Mr. Steve Cox 

Lead Communications Engineer 
MITRE 

Dr. Gary A. Federici 

Director, Information Operations and Warfare 
Center for Naval Analyses 

Mr. Thurman (Rich) Haas 

Principal Director, National Systems Engineering and Architecture Directorate 
The Aerospace Corporation 

Lt Gen John B. Hall, Jr., USAF (Ret) 

Private Consultant 

Dr. Barry M. Leiner 
Director 

Research Institute for Advanced Computer Science 

Lt Col Russel M. Mayes 

Chief, Airborne Communications 

AFCIC/SYOA 

Col John J. Murphy, Jr., USAF (Ret) 

Staff Principal Analyst 
Aerospace C 2 & ISR Center (ARINC) 

Dr. Michael P. Shatz 

Leader, Advance Systems Concepts Group 
M.I.T. Lincoln Laboratory 

Executive Officer: Capt Cristina Huerta, AFRL/VASM 
Technical Writer: Maj David E. Bossert, USAFA 


Appendix C-4 



Technology Panel 


Dr. Alison K. Brown, Chair 
President 

NAVSYS Corporation 

Dr. Thomas A. Brackey, Deputy Chair 
Executive Director, Technical Operations 
Hughes Space and Communications Company 

Dr. Duane A. Adams 
Vice Provost for Research 
Carnegie Mellon University 

Mr. Timothy M. Bonds 
Analyst 

The RAND Corporation 

Mr. John N. Entzminger 
Private Consultant 

Dr. Gene H. McCall 
Chief Scientist 
AFSPACECOM 

Prof. Alan S. Willsky 

Department of Electrical Engineering and Computer Science 
Massachusetts Institute of Technology 

Maj Kenneth S. Kreit 

Program Manager, Large Aperture Spacecraft 
National Reconnaissance Office 

Advisors: Dr. Kevin B. Kreitman, Aerospace Corporation 

Mr. Richard Metzger, AFRL/IF 
Mr. Jay Scarano, MITRE Corporation 
Maj Michael J. Estes, C2ISR Center 
Maj William Richard, SAF/AQII 

Executive Officer: Maj Timothy P. Nickerson, AMC/XPX 
Technical Writer: Maj Joseph E. Brouillard, USAFA/IG 


Appendix C-5 



Acquisition and Program Management Panel 


Maj Gen Eric B. Nelson, USAF (Ret), Chair 
Consultant 

Aerospace Industry Consulting Services 

Mr. Thomas N. Bostelaar 

Manager, C 2 Integration Line of Business 

TRW Systems and Information Technology Group 

Col John J. Colligan, USAF (Ret) 

Acquisition Systems Advisor 
MITRE Air Force C 3 Systems Center 

Lt Gen Gordon E. Fornell, USAF (Ret) 

Consultant 

Dayton Aerospace Inc. 

Maj Gen George B. Harrison, USAF (Ret) 

Director, Research Operations 
Georgia Tech Research Institute 

Dr. Mark A. Lorell 
Senior Analyst 

Rand Corporation, Santa Monica 

Dr. Kenneth C. Pedersen 

Vice President, Advanced Missile Systems 

Raytheon Missile Systems Division 

Dr. Harold W. Sorenson 

Senior Vice President and General Manager 

The MITRE Corporation 

RADM Ronald C. Wilgenbusch, USN (Ret) 

Consultant 
RCW Consulting 

Executive Officer: Capt Aaron T. Meadows, 5 CCG/CCE (ACC) 
Technical Writer: Maj Stefan B. Dosedel, USAFA 


Appendix C-6 



People and Organization Panel 


Mr. Jeffery B. Erickson, Chair 
Manager, Crew Systems 
The Boeing Company 

Col Lynn Carroll, USAF (Ret) 

Private Consultant 

Col Roger Carter, USAF (Ret) 

Program Manager, Advanced Information Systems 
Lockheed Martin Corporation 

Dr. Emily Howard 
Technical Fellow 
The Boeing Company 

Dr. Miriam E. John 

Vice President, California Division 

Sandia National Laboratories 

Maj Guy Jones, USAF (Ret) 

Senior Systems Analyst 
SenCom Corporation 

Dr. Gary Klein 

Chief Scientist and Chairman of the Board 
Klein Associates Inc. 

Prof. M. Elisabeth Pate-Cornell 

Department Chair, Management Science and Engineering 
Stanford University 

Col Bruce Queen, USAF (Ret) 

Director, Advanced Program Development Airborne Ground Surveillance & Battle Management Systems 
Northrop Grumman 

Lt Gen John B. Sams, Jr., USAF (Ret) 

Director, C17 Field Services 
The Boeing Company 

Col Hugh Smith, USAF (Ret) 

Manager, C 2 Operation 

TRW, Systems and Information Technology Group 

AFRL/HE Liaison: Dr. John Reising 

Technical Advisor, Crew System Integration Division 

Executive Officer: Maj Juan R. Berrios, ACC/INXX 
Technical Writer: Capt John M. Feland, USAFA/DFEM 


Appendix C-7 



Vision and Bridging Concepts 


Mrs. Natalie W. Crawford, Chair 

Vice President and Director, Project AIR FORCE 

RAND 

Gen James P. McCarthy, USAF (Ret) 

Olin Professor of National Security 
United States Air Force Academy 

Prof Edward A. Feigenbaum 
Stanford University 

Lt Gen Everett H. Pratt, Jr., USAF, (Ret) 

Private Consultant 

Dr. Peter A. Swan 

Chief Engineer and Vice President 

Southwest Analytic Network 


Appendix C-8 



Appendix D to Volume 2 
Top Level Organizations Visited 


7-8 March, Colorado Springs, CO, Acquisition Panel 

Lockheed Martin, Colorado Springs20-21 March, Hurlburt Field, FL, all panels 
C 2 TIG, AC2ISRC, ESC, JointSTARS, C 2 ISR Acq, C 2 Battlelab, JEFX 2000, SAF/AQI 

22-24 March, Robins AFB, GA, People and Organization Panel 

93rd Air Control Wing 

27-28 March, Orlando, FL, People and Organization Panel 

Air Force Agency for Modeling and Simulation 

3-5 April, Hanscom, MA, Acquisition Panel 

ESC 

10-11 April, Langley AFB, VA, all panels 

ACC Headquarters, AC2ISRC, ACC Network Operations Security Center 

10-12 April, Hampton, VA, Interoperability Panel 

JFCOM, JWC, JBC13-14 April, Washington DC, People and Organization Panel 

Lockheed Martin, Boeing Information Systems, US Navy, DARPA 

18-20 April, Washington DC, Acquisition Panel 

SAF/AQ, DISA, DOE 

25-27 April, Nellis AFB, NV, all panels 

Air Warfare Center, Space Warfare Center, Red Flag, ESC Programs, Boeing IRAD, USAF 
Fighter Weapons School 

28 April, Colorado Springs, CO, Acquisition Panel 

Lockheed Martin 

3-4 May, Hurlburt Field, FL, Concept and System Definition Panel 

c 2 tig 
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8-12 May, Las Vegas, NV, Concept and System Definition Panel 

Agile Combat Support Conference 

8-12 May, Washington DC, Acquisition Panel 

AFCEA sponsored Global Command and Control System course 

16-17 May, Chantilly, VA, Interoperability, Technology, and Concept and System 
Definition Panels 

NRO, DARPA 

16-18 May, Washington DC, Acquisition Panel 

DISA, USAF/XOC, SPAWAR, USAF/XOJ, SAF/AQI, USAF/XOR, USAF/SC, and USAF/XPP 

18 May, Washington DC, Concept and System Definition Panel 

DARPA 

18 May, Crystal City, VA, Interoperability Panel 

Lockheed Martin, OASD/C 3 I, JSF Program Office 

23-25 May, Langley AFB, VA, Technology Panel 

Fusion Briefings 

30 May-1 Jun, Wright-Patterson AFB, OH, People and Organization Panel 

AFRL Human Effectiveness Directorate 

7-9 June, Davis Monthan AFB, AZ, Concept and System Definition Panel 

12 June, Rome, NY, People and Organization, Interoperability, Technology, and 
Concept and System Definition Panels 

AFRL Information Directorate 

13-14 June, Hanscom AFB, MA, all panels 

ESC 

21 June, Washington DC, Interoperability Panel 

HQ US Army/DISC4 

21-22 June, Langley, AFB, VA, Technology Panel 

ISR Briefings 
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26-27 June, Interoperability and Technology Panels 

SPAWAR System Center, SPAWAR Acquisition, SWC 

26- 27 June, Washington DC, Acquisition Panel 

DISA, Ballistic Missile Defense Organization, SPAWAR, and Advance Information Technology 
Service Joint Program Office 

27- 30 June, Seattle, WA, People and Organization and Concept and System 
Definition Panels 

Boeing Phantom Works, Space and Communication 

30 June, Ft Monmouth, NJ, Interoperability Panel 

Army PEO/C3S 

10-21 July, San Jose, CA, all panels 

SAB Summer Session 

10-21 July, San Jose, CA, Technology Panel 

Oracle Corporation, Sun Microsystems, JavaSoft, TBMCS Briefing 

17 July, San Diego, CA, Interoperability, People and Organization, and Concept 
and System Definition Panels 

US Navy Co mm and Ship Coronado 

7 August, Wright-Patterson AFB, OH, Acquisition Panel 

AFMC HQ, ESC, ASC 
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Appendix 4D 
Information Assurance 


The steps taken to protect our information collection, transfer, and storage, which constitute 
information assurance, can be decomposed into the following areas: 

A. Protection of our sources of Intelligence - Information used in military operations is 
collected from many sources, including passive and active sensors. The sensors usually ride on 
platforms, such as aircraft or satellites, controlled or directed from various operations centers. 

The provide intelligence preparation of the battlefield, intelligence during operations, and 
operational effectiveness data. Sensor and platform protection are essential needs for information 
assurance. 

Finally, much of the information driving decisions in a theater war, particularly a limited conflict 
is produced by human agents. Some of these are insiders in the enemy society or force, others 
are U. S. collectors, such as Special Forces teams operating in enemy territory. In either case, it 
is incumbent on U. S. Forces to protect these sources. In some cases protection can be in the 
form of distracting or confusing information, and in other cases actual physical force may be 
necessary. The Air Force should develop basic principles for both forms of protection, at least 
where information operations or deployment of air or space power is concerned. C 2 systems must 
be able to take into account planning operations to protect our intelligence sources. 

B. Protection of the links from intelligence sources into the C 2 system - Communication 
links to sensors are vital parts of an information collection system. Control information is 
transmitted to a sensor, be it aircraft, ground force, human agent, or satellite, and information is 
transmitted from the sensor to the sensor data user. Frequently, but not always, information is 
transmitted by wireless link. Communication channels, wireless, fiber, or other, must be 
protected. There must be methods of detecting and recognizing jamming of either the command 
or response links and responding effectively. Robustness of connectivity (such as anti-jam 
capability), multiple independent transmission paths, and ability to operate with degraded 
connectivity are the most effective approaches. Corruption of data as the result of enemy 
jamming or damaging of repeater amplifiers or transmission systems is rather easy to detect even 
if repair is difficult. Error detection and correction methods can help to keep track of these 
errors. Monitoring of transmission error rate is a fundamental task for a communication system. 

Intercept of information being transmitted is a threat that can be treated in several ways. The 
classical method is through encryption, and much development of encryption methods, 
particularly public key methods, is underway in the civil, commercial, community. Quantum 
encryption techniques that provide protection through fundamental physical principles are being 
developed in government and university laboratories. This method guards against undetected 
replacement of data. These methods should be studied by the Air Force. 

Spread Spectrum communications can be used to make it difficult, or impossible to detect or 
intercept the signal. This has been used with great benefit for agent-in-place and Special Forces 
communication systems. 

C. Protection of the links within the C 2 system’s network(s) - All C 2 systems require 
connectivity between their component parts. Shared data-bases must be connected, and user 
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workstations as well. Most of these links are carried terrestrially, and increasingly are carried 
tunneled within publicly accessible connectivity such as the Public Switched Telephone Network 
(PSTN) or Internet trunks. These links must be protected from Denial of Service (DoS) attacks 
and intrusion. While NS A certified cryptos provide excellent intrusion protection and 
Transmission Security (Transec), other techniques such as link robustness, multiple redundant 
link paths, and ability to operate with degraded connectivity are essential to operating during a 
DoS attack. 

D. Protection of the data that resides within the system - Modem C 2 systems contain or 
access large data libraries and maintain a data-base containing a representation of the battlespace. 
Techniques to detect and correct data corruption, caused by random errors or deliberate 
intrusion, are essential to information assurance in this area. Destruction of information is 
usually easy to detect. Detection of replacement and corruption is more difficult. The integrity 
of stored data is primarily maintained by the storage device itself. Devices may be susceptible to 
natural or artificial electromagnetic signals. Critical storage devices should be equipped with 
detectors that will warn the user if the device experiences electric or magnetic fields that could 
disrupt data stored in the device. 

The most likely way in which data can be disrupted is through access and replacement by 
friendly users. A record of access and, particularly, modification of data by authorized users and 
applications should be kept. The record can be reviewed periodically to determine if dangerous 
corruption may have occurred. 

Retrieval errors are similar to transmission errors, and the considerations for transmission errors 
apply. In addition, retrieved information is usually directed to a predetermined location. 
Misdirection is possible as the result of enemy action, human error, or computer equipment 
failure or program bugs. Misdirection is easy to detect, but real-time analysis of the reason for 
misdirection will be very useful in eliminating the problem. 

Computer program bugs do not always appear during simulation, exercise, or beta testing of 
applications. All of those methods provide valuable, but somewhat idealized situations. Data 
and application interactions that are unanticipated may cause conflicts and errors that can even 
be catastrophic. Applications can be analyzed and tested for the most common errors. Records 
of errors and their resolutions should be kept. Detection and repair methods can eventually be 
included in compilers or, even, in the applications themselves. 

The threat from knowledgeable and treacherous insiders can never be completely eliminated. 
Constant vigilance must be maintained. An unlikely, but potentially catastrophic, danger is from 
malicious compiler and tool designers. As the Air Force becomes more dependent on 
commercial products, some, or many, of these products will be manufactured abroad. 

The operating system is the heart of any computer. Access to all the capabilities of the computer 
and many of those of the network can be gained through unrestricted access to the operating 
system. 

Vulnerability to penetration can be through compromise of passwords, classical “hacking” 
methods, or trap doors. Existing and new applications should be scanned to make sure that 
access violations will not occur. 
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E. Protection of the links the system uses to command external resources - The links the 
system uses to command action, either of battle resources or of intelligence collectors, are 
subject to the same sort of attack as the links from our sensors. They may be protected using the 
same techniques. 

Technologies being developed to provide information assurance are summarized in the following 
tables. 


Table 4D-1. Secure Networking 


Problem 

Technology 

Description 

Internet routing infrastructure subject 
to denial of service attacks 

Secure OSPF (open shortest 
path first) routing protocol 

Nimrod routing security 

Authentication added to routing 

Internet naming and addressing 
infrastructure is vulnerable to denial 
of service attacks 

Internet Protocol (IP) version 6 
(IPv6, also known as IPsec) 
prototype 

Secure Domain Name Service 
(DNS) protocol 

IPv6 encrypts IP packets 

Secure DNS adds authentication 
and authorization to DNS 

Network security services are not 
easily integrated into applications 

Cryptographic application 
programming interfaces (CAPI) 

Simple public key interface 
(SPKI) 

Key mgmt interfaces 

These interfaces give programmers 
standard ways of adding security 
functionality to software 

Network security services are not 
interoperable 

IPsec key agreement protocol 

Secure Mobile IP 

Multi-layer security negotiation 
protocol 

Mobile IP security protocol 
preserves user identity for nomadic 
users traveling across different 
networks 

Encrypting group communication and 
managing membership changes not 
scalable to large groups 

Secure fault-tolerant group 
communication 

Scalable algorithms for key 
management and membership 
revocation, and language for 
specifying group communication 
policies 

Traditional operating system security 
inappropriate for modern networked 
environments with complex policies 

Domain-Type Enforcement 
(DTE) 

Fine-grain access control and an 
associated policy “compiler” 

Adequate security available only in 
special-purpose OS’s with tiny 
market 

Fluke operating system 

Security is being integrated into 
commercially viable next-generation 
OS’s 

Distributed systems meeting more 
than one critical property are beyond 
the state of the art 

Horus distributed computing 
system 

Group communications system 
supporting secure, real-time, fault- 
tolerance 

Rigid security and firewalls inhibit 
tightly coupled cross-domain 
applications and establishment of 
temporary security associations 

Adage authorization server 

Sigma security middleware 

A distributed authorization server 
and policy language 

Propagation of access control 
information across enclave 
boundaries 
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Table 4D-2. Detection and Tolerance 


Problem 

Technology 

Description 

Current intrusion detection 
techniques are limited to detecting 
a small set of well-known events 

Emerald intrusion detection 
system 

Detects unknown attack types on 
networks 

Current detection techniques do 
not scale, and do not support 
automated response 

— GRIDS intrusion detection 
system 

— Allows attacks to be specified 
as a graph across a network, thus 
allowing detection of larger-scale 
attacks 


— Intrusion Detection and 

Isolation Protocol (IDIP) 

— Allows coordinated detection 
and automated response 

Current technology does not 
support incident response, which 
is costly labor-intensive process 

DERBI (Diagnosis, Explanation 
and Recovery from computer 
Break-Ins) 

Tool to analyze a system for 
indicators of a possible intrusion. 
DERBI explains to the system 
administrator what it found, what it 
likely means, and how to recover. 

Lack of standards impedes 
adoption of even current 
technology 

Common Intrusion Detection 
Framework (CIDF) 

Establishes standard interfaces 
for event generators (sensors) 
and analysis engines (detectors) 

Current intrusion detection 
detects only attacks on isolated 
machines rather than on the 
network infrastructure 

JiNao intrusion detection system 

Detects intruders in network 
routers, switches, and network 
management channels. Integrated 
with network management and 
has reconfiguration capabilities 

Multicast group communication 
protocols vulnerable to malicious 
participants 

Secure Group and Secure Ring 
protocols 

Group communication protocols 
that can prevent a malicious 
processor from disrupting the 
correct delivery of messages and 
from denial of service attacks 

Common programming errors 
leave most systems vulnerable to 
buffer overflow attacks, the most 
common type of attack on the 
Internet 

Stackguard compiler 

Programs compiled with 

StackGuard are not vulnerable to 
buffer overflow attacks. No source 
code changes are required, and 
executables are binary- 
compatible with existing operating 
systems and libraries 
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Table 4D-3. Wrappers 


Problem 

Technology 

Description 

Commercial products introduce 
unreliability and security risks 

Generic Security Wrappers 

Wrapper technology to augment 
legacy & COTS components with 
security functionality. Includes a 
wrapper specification language 
and a kernel-resident wrapper 
system. It intercepts system calls 
to control privileged and non- 
privileged programs. 
Demonstrations include control of 
administrative privileges, access 
control, and encryption 

Integrators cannot assemble 
components and wrappers into a 
trustworthy whole 

Composable Replaceable 

Security Modules 

A tool to build security into 
systems by assembling security 
functions from a library of 
reusable, plugable security 
modules, with standard 
functionality and interfaces 

Evaluation of 

vulnerability/resistance of a 
product or system 

Vulnerability Assessment Tool 

White-box security evaluation tool 
locates vulnerable points in 
source code, using realistic attack 
models and taxonomies of known 
security flaws 
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Appendix 4E 

Revolution In Battlefield Awareness Of 
Advanced Ground Moving Target Radar 


There is a significant technical advancement in Ground Moving Target Indication (GMTI) radar 
for tactical and strategic Intelligence, Surveillance and Reconnaissance (ISR) that will provide a 
major leap ahead in the Dominant Battlespace Awareness for the battle commander required to 
satisfy Joint Vision 2010. 

Rather than just slowly updated moving dots, advanced GMTI radar systems will be able to 
provide high update moving target detection and individual target features thus providing much 
higher quality information about the nature and dynamics of thousands of moving targets over 
large areas. This information will include accurate geo-registered target location; velocity of the 
target; simultaneous feature measurements of individual moving targets such as size, high range 
resolution (HRR) profile (ID), and synthetic aperture radar (SAR) and Inverse SAR (ISAR) 
which produces 2D images of both fixed and moving targets. This enhanced information thus 
provides a dynamic picture of vehicle characteristics, speed, where they are coming from and 
going to, and the number of vehicles moving in specified areas. The vehicle features or 
attributes coupled with high update track data provides significant information concerning type 
of military unit convoy characteristics such as: number, type and mix of vehicles; vehicle traffic 
and passing activities as a function of road type; mix of civilian vs. military traffic; indications of 
roadblocks, bridges or other traffic constrictions; associated helicopter movement, congregation 
of vehicles at areas that can be command posts or logistics/refueling areas; traffic sources such as 
known military installations; and traffic sinks or destinations that can be associated with military 
units etc. 

GMTI radar high update detections coupled with high range resolution vehicle feature 
information is significantly different from imagery. Finding stationary enemy targets in large 
areas with high resolution imagery can overwhelm the exploitation task (20 to 200 Mbits/sec) 
and requires large numbers of highly trained human image analysts to exploit. Automatic or 
computer aided target recognition of SAR imagery can help cue the human analyst but is not yet 
an automatic process and will always require large processors. On the other hand, advanced 
dynamic GMTI radar detections and their associated high resolution target feature information is 
a fairly low data rate information stream (100’s Kbits/s to a few Mbits/s dependent on vehicle 
count) that can be processed automatically. If processed into tracks, with associated target 
recognition tags, this data becomes at least an order of magnitude lower than even the raw GMTI 
data. Not only is GMTI track data easier to analyze, the tracks lend themselves to further 
automated track analyses such as: 

• Multiple hypothesis tracking (position, time, velocity and direction) 

• Counting of number of vehicles as a function of areas or boundaries 

• Source determination of target vehicles & their destination including traveled road/path 

• History of movement over time 

• Target evidence and recognition feature accrual and comparison over time 

This automatic analysis of moving target information is significantly easier and faster than that 
required for the analysis of complex imagery by either human or automatic image recognition. 
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As stated before this is a common experience of every hunter or fighter pilot which can easily 
spot moving game or aircraft but has difficulty seeing stationary targets even when close. 
Dynamic GMTI information and tracks are inherently time/geo-registered, provides immediate 
indication and warning information and correlates well with imagery and signals intelligence 
data thus providing a Common Operating Picture (COP) of the battlefield. GMTI tracks can 
come from simultaneous multiple radar sources that can be automatically fused together by new 
techniques in computerized multiple hypothesis processes. 

The new advanced GMTI radars will provide update rates that are dynamically adjustable 
depending on target dynamics (velocity, acceleration, on-off road, intersecting roads), range, 
terrain visibility, warfighter area of interest, location accuracy required and other target track 
filter needs. The enemy has a very difficult task to hide, conceal or confuse large numbers of 
vehicles dynamically moving in the open. GMTI by its very nature provides a truth picture of 
enemy movement and intention particularly if the enemy intent is to engage in battle. 

Not too long ago, military commanders thought of GMTI surveillance radar of the ground as a 
snap shot picture of what was moving at a point in time. The venerable Army Mohawk SLAR 
was an example of that type of picture which was hardly dynamic in nature but gave a picture of 
the number of moving vehicles at a point in time. In the early 1980’s, technology progressed to 
the point where passive phased array GMTI radars could provide a wide area picture of moving 
targets every 30 to 60 seconds providing a more dynamic update of target movement even if it 
was only moving dots or blobs. 

These current GMTI radars do a good job of detecting mass enemy movements and providing a 
degree of battlefield awareness. But, the information lacks target recognition features and is 
therefore a moving history of dots or blobs with insufficient update rate for significant tracking 
over large areas. The data can be registered on terrain maps or images with a background of 
apriori terrain and road database information. A compressed time history of the data shows a 
human analyst enemy target movement portrayed as a strobe or smoke trail on the display that 
allows human operators to discern movement and direction and learn to recognize characteristics 
of enemy motion. The radars are not able to provide continuous GMTI because of insufficient 
power-aperture, the need for interruptions to collect SAR imagery (15-45 sec depending on range 
and resolution) as well as blanks in data due to aircraft orbit turns (lasting 3-5 min). Because of 
these gaps, the lack of target feature measurements and their slow update rates, these radars are 
limited in their ability to provide battlefield intelligence, reconnaissance, battle damage 
assessment, or precise moving target location capability. They are, however, very useful as 
indications and warning, battle management and command and control systems for providing 
battle commanders information on enemy motion and the timing of events as well as providing 
coarse information for target - weapon pairing and subsequent target reacquisition by strike 
forces. 

Radar Technology Advances 

Technical GMTI advances have occurred in the past few years that significantly changes the 
capability to provide even more useful dynamic battlefield information. Some of the major 
technical advances are: 

• Active Electronic Scanned Arrays (AESA) (ID or 2D steering) use distributed low cost solid state 
modules to feed each radiating element: 
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• The resulting AESA is a highly modular and scaleable approach that will allow significantly 
lower manufacturing cost over that of older tube transmitter designs 

• Production MMIC Transmit / Receive (T/R) X band (8-12 GHz) modules typically come in 1, 5 
or 10 watt powers and are projected to cost less than $500 per radiator site. 

• T/R modules in close physical proximity to the radiating elements have both high efficiency and 
much lower losses thus providing high effective radiated powers. 

• Planar multi-layer printed circuit board manifolds distribute low voltage DC prime power, low 
level RF signals and digital control signals to the active T/R modules. 

• Compact, distributed, high power solid state low voltage DC power supplies feed power to the 
T/R modules. 

• The T/R modules and radiating elements have multi-giga Hertz tuning ranges and very wide band 
instantaneous bandwidth capable of ultra high resolution waveforms. 

• The solid state T/R modules have very high reliability and graceful degradation that can approach 
the life of the airframe carrying it. 

• The continuing march of faster and faster embedded digital signal processors currently allows 
greater than 100 Giga-Operation/second per cubic foot, with the promise of Tera-Ops/cubic foot 
in the near future 

• Wide band frequency hop/chirp exciter/receivers with capability for greater than 1 GHz 
instantaneous bandwidth will provide high resolution modes from 0.1 to 1 meters and tuning 
ranges in excess of multiple GigaHertz. 

• Active aperture radars allow simultaneous/interleaved pulse to pulse modes (GMTI, High Range 
Resolution (HRR) and SAR Imaging) with manageable performance degradation from operating 
in these simultaneous modes. 

• Advanced processing schemes for multi-beam Space Time Adaptive Processing (STAP) allows 
improved cancellation of moving ground clutter as well as adaptive spatial nulling of jammer and 
interference signals. 

• Automatic moving target tracking of large number of targets using Multiple Hypothesis Tracking 
(MHT) and kinetic and Kalman filter algorithms. Such trackers use feature evidence 
accumulation and pruning to sort out targets from false alarms and confusing dense adjacent 
traffic even in the presence of road intersections and drop outs. 

• Automatic moving target feature recognition using High Range Resolution (HRR) one 
dimensional range profiles of large numbers of targets (measured in 0.1 to 0.2 secs/measurement) 
as well as 2D imaging using both inverse SAR techniques (1-3 secs) as well as Moving Target 
Imaging (MTIm) SAR (10-30 secs) that is able to image moving targets. The speed of the HRR 
mode works very well to aid automatic trackers to provide feature evidence to rapidly recover 
track drop outs in dense traffic or confusing road situations. Initial tests of multi-look HRR at 1ft 
resolution has achieved target recognition in the 85-95% range. HRR will also provides target 
fingerprinting to aid track maintenance. 

Summary of Modern Active ESA GMTI/SAR Radar 

The new advanced airborne GMTI radar can provide a significant source of tactical, theater and 
even strategic intelligence about dynamic enemy force movement thus providing revolutionary 
performance in battlefield indications and warning, synoptic battlespace awareness, 
target/weapon pairing information and real time wide area battle damage assessment unlike any 
in the past: 

• High update rate track of 1000’s of individual vehicles over wide areas and at significant ranges 
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Target recognition that turns moving dots into recognized target entities 
Automatic real time signal and data processing 

Significant intelligence about enemy forces such as automatic sentinels around areas, vehicle 
counts, sources/sink detection, convoy and group detection and tracking data and history of 
movements. 

Interleaved, simultaneous GMTI, SAR and target recognition modes 

Ultra high resolution SAR spot images with 2-3 times the resolution of current fielded systems 

Advanced GMTI/SAR Radar Modes 
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Figure 4E-1. Advanced GMTI/SAR Radar Modes 
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Appendix 6C 

The Current Air Force Acquisition Process for C 2 Systems: 
A Case Study of TBMCS 


Summary 

The Theater Battle Management Core Systems Program (TBMCS) is the current Air Force 
flagship program for automating and integrating the planning and execution of the theater air 
war. This report provides a detailed developmental case history of TBMCS from the late 1980s 
through June 2000. This case study was commissioned by the Acquisition Panel of the US Air 
Force Scientific Advisory Board (SAB) 2000 Summer Study entitled “Air Force Command & 
Control—the Path Ahead.” It is intended to illustrate how the Air Force developed and procured 
its most important tactical command and control systems in the 1990s. The purpose of this case 
study is to help identify areas where the Air Force can improve its acquisition strategies in the 
future for tactical command and control systems. The account presented here is based almost 
entirely on interviews with key Air Force and industry participants in the TBMCS program, as 
well as on the extensive historical written documentation of the program made available to the 
author by the TBMCS Program Office located at the Electronic Systems Center, Hanscom Air 
Force Base. 

The five core functions of TBMCS can be defined as (1) intelligence collection and evaluation, 
(2) planning, (3) generating and distributing the Air Tasking Order (ATO), 53 (4) unit level 
scheduling of missions; and (5) monitoring execution of the ATO. TBMCS is intended to link 
these intelligence, planning, and operations functions through the integration of several legacy 
systems (or their equivalent functional capabilities), the most important of which are the Combat 
Intelligence System (CIS), the Contingency Theater Automated Planning System (CTAPS), and 
the Wing Command and Control System (WCCS). In addition, TBMCS migrates these key 
theater air warfare applications to the Defense Information Infrastructure Common Operating 
Environment (DII COE). 54 

TBMCS has experienced a troubled and controversial history since its formal launch in late 
1995, when Loral Command and Control Systems (LCCS, now Lockheed Martin Mission 
Systems [LMMS] of Colorado Springs) won a six-year competitive cost plus award fee (CPAF) 
contract valued around $180 million. The program has suffered from significant schedule 
slippage, some cost growth, and major performance short falls. 55 The original concept 


53 The ATO is a method used to task and disseminate to components, subordinate units, and command and control 
agencies projected sorties/capabilities/forces to targets and specific missions. Normally it provides specific 
instructions to include call signs, targets, controlling agencies, etc., as well as general instructions. (See the 
Defense Technical Information Center (DTIC) DoD Dictionary of Military Terms). 

54 The DII COE is DoD’s common software infrastructure, architecture, and set of guidelines and standards, which 
will be used for all military C4I systems, such as the Global Command and Control System (GCCS). 

55 The original contract value to the prime contractor was $35 million (excluding fee, zero base fee), with options 
that were eventually exercised amounting to $109 million, resulting in a total of $144 million. Award fees and 
miscellaneous changes raised this to $179 million. A category labeled “evolutionary Requirements (technical task 
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envisioned the fielding of three progressively more capable software releases, with the final V 
3.0 release available in 2001. Early in the program, release of Version 1.0 was planned for 
March 1998. Instead, as of June 2000, the program still had not been able to successfully 
complete and field Version 1.0. In addition, the Version 1.01 represented a significant down¬ 
scoping in the capabilities envisioned earlier for the first release. 56 As a result, many observers 
have viewed TBMCS as a seriously flawed program with regard to its development process and 
other factors, at least in the early phases. 

As of mid 2000, however, the program generally appeared to be on track. A detailed plan for the 
fielding and future upgrading of the system has been developed. 57 Nonetheless, its many 
problems make it worth examining carefully for “lessons learned” for future Air Force 
approaches for tactical C 2 systems acquisition. It is a story that the Air Force should avoid 
repeating. 

Based on this detailed case study, we conclude that the problems experienced on TBMCS were 
caused primarily by the following factors: 

Lack of sufficiently detailed concept of operations (CONOPS), concept of employment 
(CONEMPS), system architecture, and operational requirements. TBMCS was launched 
with a strong visionary high-level CONOPS and system architecture. However, these lacked the 
detail necessary to provide appropriate guidance to the Air Force and contractor Program 
Managers (PMs) for development of the system. No formal Operational Requirements 

CO 

Document (ORD) was ever produced. The problem was compounded by the lack of consensus 
among the user communities over CONOPS and operational requirements, and by continual 
change and evolution. The constant refrain of the contractor remained throughout the program: 
“Will the real user please stand up?” 59 

Lack of consistent, strong advocacy leadership on the highest levels of the Air Force, and at 
the SPO and contractor levels, particularly during crucial points during the program. 

Initially TBMCS had a few strong advocates on the highest levels of the Air Force. This is 
particularly true during the very early phases of the program when John Gilligan was the 
Program Executive Officer (PEO). Yet at one key point during the development phase, an Air 
Force Major, far down in the SPO hierarchy, acted as the de facto PM for at least six months 
during a crucial development period. The program lacked clear lines of authority and strong 
leadership both on the government side and the contractor side. Perhaps most important, there 
was no single powerful focal point of responsibility, advocacy, and oversight for the program. 
This was particularly true in the area of requirements development. 

Inappropriate application of current acquisition reform (AR) doctrines of transferring 
greater system definition responsibility to the contractor. Partly by default, and partly 


descriptions)” added an additional $161 million, for a total contract value in mid 2000 of $327 million. Mr. Steven 
Kent, ESC, provided this information. 

56 However, TBMCS Version 1.01 also includes other capabilities not envisioned in 1995 

57 TBMCS passed its Field Demonstration Test in June 2000. A Multi-Service Operational Test & Evaluation took 
place in late July. 

58 CTAPS and WCCS did have formal System Operational Requirements Documents. 

59 Interview by author with Reese Delorey, TBMCS Lockheed Program Manager, 15 April 2000. 
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because of DoD acquisition reform doctrine, program officials granted the prime contractor 
significant control over the development of the system operational architecture, configuration, 
and even CONEMPS. Especially in the early phases of the program, the contractor senior 
management lacked the operational knowledge, technical skills, and initiative to meet this 
challenge effectively without greater guidance from the Air Force. Clear guidance was not 
forthcoming, because no consensus existed in the Air Force on these issues. 

Use of a “big bang” development approach instead of a spiral approach, which delayed 
fielding, and resulted in operator pressure to divert resources to fixing legacy systems. 60 

The TBMCS contract called for the development and fielding of three major software releases 
over a six year period. The user community lobbied hard for a much quicker fielding of initial 
capabilities. This led to the decision to divert significant resources to fixing existing fielded 
systems (CTAPS, CIS, WCCS). This effort proved far more difficult than anticipated, leading to 
significant delays in the TBMCS program, because the fielded legacy systems were seriously 
flawed. In theory, a spiral development approach could have led to a much earlier fielding of 
initial capabilities, thus reducing the pressures to divert resources to fixing legacy systems. 

Insufficient “jointness” in the original program planning vision. Failure to include sufficient 
joint vision in initial program planning contributed to the unanticipated need to rehost CTAPS to 
Sun Solaris and HP Unix servers for Navy shipboard operations. This was identified as a major 
unplanned diversion of resources. In general, Navy requirements and needs were not sufficiently 
recognized in the early phases of the program. The scale of the Air Support Operations Center 
(ASOC) upgrade program effort for the Army Corps level was also underestimated. 

Underestimation by both the government and prime contractor of the technical difficulty of 
integrating legacy systems. Multiple contractors had developed the legacy software modules 
which would go into TBMCS, usually in conjunction with a specific government laboratory and 
a specific user command. Thus the pieces that would make up TBMCS had no uniformity in 
architecture, computer language, etc. Little formal documentation existed, resulting in 
difficulties in transferring the necessary legacy information to Lockheed. This problem was 
exacerbated by third party “associate” contractors which had no formal contractual relationship 
with Lockheed. Finally, some particularly troublesome modules, such as FLEX, were developed 
by labs as technology demonstrations, and were not appropriate for fielding. In the case of 
FLEX, neither the SPO nor Lockheed had direct control over development. Finally, virtually all 
the legacy modules were more immature technically than originally anticipated. One TBMCS 


60 Spiral Development is a developmental process commonly used in the commercial software world for incremental 
development and rapid fielding of new capabilities. It is based on iterative, short development cycles that focus on 
risk areas, and which integrate users, developers, acquirers, and testers. Air Force Instruction 63-123 Evolutionary 
Acquisition for C2 Systems, 1 June 2000, provides a guide for mandatory use of the spiral development process in 
Air Force C2 development programs. Some authorities believe this document does not adequately describe the 
process of spiral development as used in the commercial world. For one discussion of the concept, and the problems 
of implementing it in military C2 acquisition programs, see the briefing WG4 Institutional Challenges, prepared by 
members of the Spiral Workshop, February 2000, sponsored by the Carnegie Mellon Software Engineering Institute, 
and the Center for Software Engineering, University of Southern California. 
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Program Manager summed up this issue by noting: “the biggest failure of TBMCS has been 
setting unrealistic levels of expectations.” 61 

Inadequate process for controlling and screening requirements and capabilities 
development and additions. The user community continued to develop independently new 
modules and capabilities that were progressively folded into the program. No process existed to 
assess, prioritize, and filter these, leading to much added integration work for the prime 
contractor. Little discipline was exercised over requirements growth and change by either the 
government or the prime contractor, since no clear baseline configuration was ever established 
early in the program. 

Lack of an appropriate strategy for testing and fielding the system. The program did not 
develop a consensus on a unified testing concept and approach, nor on test metrics forjudging 
success. A lack of a unified and detailed CONOPS and CONEMPS resulted in the lack of a 
standard use pattern by users. Different testers, with different use patterns, and using different 
test metrics, conducted the various operational and fielding tests, producing widely varying 
results. 


The following section, a case study of the development of TBMCS, has not been cleared for 
public release. In the event you have a need to obtain this information, please contact the 
Executive Director of the U.S. Air Force Scientific Advisory Board at (703)-697-4811. 


61 Note to author from Carl Steiling, 18 August 2000. 
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Acronyms 


AADC 

ACC 

ACC/DR 

ACPT 

AFMC 

AFMSS 

AFOTEC 

AFSC 

ALC 

AMC 

AOC 

APS 

AR 

ASOC 

ASP 

ATO 

BSD 

C 2 IPS 

C3 

CAF C 2 SPO 

CAFMS 

CAOC 

CCB 

CIS 

CMM 

COP 

COTS 

CPAF 

CTAPS 

CTIS 

DE 

DIA 

DII COE 

DISA 

DR 

DRs 

ECP 

EOB 

ESC 

Evms 

Fdt&E 

FFRDC 

FLEX 

FYDP 

GCCS 

GOSG 

GTACS 

GTN 


Area Air Defense Commander 
US Air Force Air Combat Command 
Deputy Chief of Staff for Requirements, Air Combat 
Command 

Air Campaign Planning Tool 

Air Force Materiel Command 

Air Force Mission Support System 

Air Force Operational Test and Evaluation Center 

Air Force Systems Command 

Air Logistics Center 

US Air Force Air Mobility Command 

Air Operations Center 

Advanced Planning System 

Acquisition reform 

Air Support Operations Center 

Acquisition Strategy Panel 

Air Tasking Order 

Battlefield Situation Display 

Command and Control Information Processing System 
Command, control and communication programs 
Combat Air Forces Command and Control System Program 
Office 

Computerized Assisted Force Management System 
Combined Air Operations Center 
Configuration Control Board 
Combat Intelligence System 
Capability Maturity Level 
Common operational picture 
Commercial-Off-the-Shelf 
Cost Plus Award Fee 

Contingency Theater Automated Planning System 
Command Tactical Information System 
Domain Engineering 
Defense Intelligence Agency 

Defense Information Infrastructure Common Operating 
Environment 

Defense Information Systems Agency 

Directorate of Requirements 

Deficiency Reports 

Engineering Change Proposal 

Enemy order of battle 

Electronic Systems Center 

Earned Value Management System 

Final Development Test and Evaluation 

Federally funded research and development center 

Force Level Execution 

Five-Year Defense Plan 

Global Command and Control System 

General Officer Steering Group 

Ground Theater Air Control System 

Global Transportation Network 
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ICM 

IDE 

INEL 

INRI 

JAT 

JFACC 

JFAT 

JMCIS 

KLFs 

FCCS 

EMMS 

MAJCOMS 

MAOC 

MCFs 

MENS 

MIDB 

MOT&E 

NAFs 

O&M 

OB 

ORD 

OTAS 

PACAF 

PE 

PEO 

PM 

PMR 

Pri 

R/SAOC 

RAAP 

RFP 

SAB 

SAIC 

SEOCs 

SON 

SOR 

SPAWAR 

SSEB 

STRATCOM 

SWPS 

T/DRs 

TAG 

TAP 

TBM 

TBMCS 

TSPR 

TTDs 

WCCS 


Intelligence Correlation Module 
In-process Design Evaluation 
Idaho National Engineering Laboratories 
Inter-National Research Institute Inc. 

Joint Acceptance Test 

Joint Force Air Component Commander 

Joint Fielding Acceptance Test 

Joint Maritime Command Information System 

Key legacy functions 

Loral Command and Control Systems 

Lockheed Martin Mission Systems 

Major Commands 

Modular Air Operations Center 

Mission critical functions 

Mission Needs Statements 

Military Integrated Data Base 

Multi-Service Operational Test & Evaluation 

Numbered Air Forces 

Operations and Maintenance 

Order of Battle 

Operational Requirements Document 
Operational Test Assessments 
Pacific Air Forces 
Program Element 
Program Executive Officer 
Program Manager 
Performance Metrics Reporting 
Priority 

Regional/Sector Air Operations Center Modernization 
Program 

Rapid Application of Air Power 

Request for Proposal 

US Air Force Scientific Advisory Board 

Science Applications International Corporation 

Single Lines of Code 

Statement of Need 

System Operational Requirements Documents 

US Navy Space and Naval Warfare Systems Command 

Source Selection Evaluation Board 

Strategic Command 

Strategic Warfare Planning System 

Test Discrepancy Reports 

Tactical Air Command 

THEATER AIR PLANNING 

Theater Battle Management 

Theater Battle Management Core Systems Program 
Total System Performance Responsibility 
Technical Task Descriptions 
Wing Command and Control System 
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Appendix 6D 

GCCS Integration Process 


GCCS Integration Process 


Microsoft Model 


GCCS Model 


Configuration Managed 
Operating System (Windows 2000) 


Tightly Integrated 
Killer Applications (Power Point) 
Partner Developed 
Applications (Quicken) 


-L 



Windows 


- MARKET SHARE 


Configuration Managed 
Operating System (COE Kernel) 


Tightly Integrated 
Killer Applications (COP) 
Partner Developed 
Applications (13*, METOC) 



- INTEROPERABILITY - 



* 13 - Integrated 
Imagery and 
Intelligence 

** IV&V- 
Independent 
Verification 
and Validation 
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Appendix 6E 

GCCS Mission Applications Schedules 


Mission Applications Schedule 
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Mission Applications Schedule 

(continued) 
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Appendix 6F 

GCCS Mission Applications Abstracts 


Fielded 

Coming 

Air Force Option 4 

• ACOA 

COMPASS NT 

• AJMRR 

COP Embedded Training 

• AMHS MM 

Front Page (T)(S) 

• COMPASS 

GCSS COP-CSE 

• DMS-T (T) 

GRISWI 

• FMEDIT 

GSORTS (E) Input/Output 

• GCSS 

JET (T)(S) 

• 13 

MAT 

• IDM 

METOC JMS/MIS 

• JDP 

METOC TFS 

• JFRGII 

NetMeeting (T) 

• NICKA (T) 

Office97 (T)(S) 

• NWCOMS (T) 

PC-Xware (T) 

• Secret Agent(S) 

Remote Dial-In (T) 

• TARGET 

RQT (T)(S) 


Seagate Backup (T)(S) 


Secret Agent (T) 



The abstracts are located on the following pages and on the SIPRNet at: 
http://cficms.osf.disa.smil.mil: 1110/aug_home/gccs301/stage2/abstracts/stage2_abstracts.html 
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Air Force Option 4 


1. System Description 

Air Force Option 4 (AFOPT4) provides GCCS 3.0.1 a direct interface to CTAPS, ATO/ACO 
query capabilities, and graphic and tabular displays of ATO/ACO data. AFOPT4 is comprised 
of three segments, GARDP, CAFMS-X(G), and Task View: 

GARDP: The GCCS Air Tasking Order (ATO) Review and Dissemination Package 

(ARDP) and ATO Airspace Control Order (ACO) Tool (AAT), provides file management and 
viewing capabilities of ATO/ACOs. It accesses the CTAPS thru SMTP mail to pull the entire 
ATO. 

CAFMS-X: The Computer-Assisted Force Management System provides GCCS users read¬ 
only access, using X-Windows, to the Contingency Theater Automated Planning System 
(CTAPS) via a connected Air Operations Center. It accesses the CTAPS via SQLNET queries. 

Task View: The Air Force Mission Planning Systems (AFMPS) ATO Task View provides 
access to USMTF ATO/ACO data to query and to display non-COP, multiple graphical views of 
message components. 

AFOPT4 tools provide an interim capability for ATO/ACO access and viewing until the fielding 
of Theatre Battle Management Core System (TBMCS). TBMCS, a Joint Staff program with Air 
Force as Executive Agent, is a DII COE compliant, joint air operations planning and execution 
application. It replaces non-Y2K CTAPS with a new, Y2K compliant ATO/ACO tool, which 
uses the joint standard USMTF 98. Therefore, it should be noted that GARDP and CAFMS-X 
segments will not be able to function after TBMCS is fielded, as they are dependent on CTAPS. 
Task View can partially function, since it uses an enhanced message format, USMTF 95-3. 
NOTE: a GCCS-TBMCS interface is required to use Task View. As of first quarter FY99, no 
interfaces have been scheduled for GCCS 3.0.1. 

2. System Requirements 

All segments of the AFOPT 4 application reside on the Solaris Platform. CAFMS-X depends on 
Oracle Client Applications and Netscape Web Browser. Task View and GARDP have no 
external software requirements 

3. Users/Training 

AFOPT4 was created to provide an alternative for GCCS users who receive ATO information 
via floppy disk or FTP. Training for AFOPT4 is developed by the Air Force and consists of 
interactive web-based functionality and downloading of training programs from the Air Force 
Web Page. Because of its limited timeline usage, AFOPT 4 training will be completed at the 
journeyman level only. 

4. Points of Contact 

The GCCS Program Management Office POC is Maj Cooper (703) 735-8611. 

The GCCS Engineer POC is Cindy Hopkins (703) 735-8754. 


Appendices 6-14 



COMPASS NT 


1. System Description 

COMPASS is a set of Government Off-The-Shelf (GOTS) and Commercial Off-The-Shelf 
(COTS) software services. COMPASS provides a non-intrusive middleware approach that 
facilitates Collaborative Planning, Modeling & Simulation (CPM&S) access as well as 
Distributed Collaborative Planning (DCP) to the Joint-Combined Arms environment. 

COMPASS allows planners using disparate mission planning systems to move between local 
planning, collaborative planning, analysis, and simulation-based rehearsal modes. COMPASS 
capabilities include a client-server architecture with session management (SMGT) tools, a shared 
overlay manager (SOM), a composite route preview (CRP) capability, COTS DCP tools, GOTS 
DCP server tools, and the ability to observe external M&S products on host C 4 I and mission 
planning systems. 


COMPS (SOL, NT) 

[GOTS] 

The COMPASS server segment is a set of four tightly integrated servers: Session 
Management (SMGT), Shared Overlay Management (SOM), Composite Route 

Preview (CRP), and Track/Simulation Management (TSM). Each of the COMPASS 
servers has a companion client library that is integrated within a modeling, planning, or 
simulation client application (e.g., GCCS, CTAPS, AFMSS, and ModSAF). These 
client libraries process remote procedure calls from the client application to their 
companion server in order to exchange modeling, planning, and simulation data with 
other client applications via the COMPASS server. COMPS also provide two 
applications: Server Control (for starting and monitoring COMPASS sessions) and 

Test Client (for developmental testing or COMPASS session monitoring). 

COMPC (HP, SOL, NT) 
[GOTS] 

The COMPASS client library segment is a set of four statically or dynamically linkable 
function libraries (SMGT, SOM, CRP, and TSM). These libraries are code-integrated 
within a COMPASS client application and process remote procedure calls from the 
client application to their companion COMPASS server in order to exchange modeling, 
planning, and simulation data with other COMPASS client applications. 

GCPA (HP, SOL) 

[GOTS] 

The GCCS Collaborative Planning Application (GCPA) is a Dll COE compliant 
application that uses the COMPASS Client Libraries (COMPC) to exchange planning, 
modeling, and simulation information with other COMPASS-capable systems via the 
COMPASS servers (COMPS). GCPA uses the Dll COE Joint Mapping Tool Kit 
(JMTK), the Track DataBase Manager (TDBM), and the UB communications 
infrastructure to interface with the underlying GCCS system. Every message received 
from the COMPASS servers by the GCPA is processed and represented in some way 
to the user of the GCPA, either on the GCPA GUI or the GCCS system chart. GCPA 
also has menu options to launch multimedia applications such as audio, video, chat, 
and whiteboard. 

GCPA Patch 1 HP, SOL) 
[GOTS] 

GCPA Patch 1 modifies the GCCS Account Group segment (after installation of the 
CVWC segment) to enable launch of the CVWC application from the main menu. 

CVWC (HP, SOL) 

[Public Domain, licensed by 
Mitre] 

Version 

The Collaborative Virtual Workspace (CVW) client segment provides an intuitive 
method for the COMPASS user to enter and leave COMPASS sessions. CVWC 
automatically launches and terminates COMPASS applications to reduce workstation 
user workload in a distributed collaborative planning environment. See also SD, an 
alternate method for launching VAT and VIC/NV. 

CVWC Patch 1 (HP, SOL) 
[Public Domain, licensed by 
Mitre] 

CVWC Patch 1 modifies CVWC to enable launch and termination of GCPA and RWC 
as COMPASS sessions are entered or left by the workstation user. Unpatched CVWC 
launches and terminates only VAT and VIC. 
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CVWS (SOL) 

[Public Domain, licensed by 
Mitre] 

Version 

The Collaborative Virtual Workspace (CVW) server segment provides a central 
administrative facility for setting up virtual conference centers and their subordinate 
sessions. Virtual conference centers and their sessions are accessed by CVWC. 

RWS (SOL, NT) 

[COTS, licensed by 

VisualTek Solutions, Inc] 

The Rendezvous Whiteboard server segment is the server component of an 
Internet/Intranet Whiteboard. RWS allows simultaneous text sessions, drawing on a 
shared canvas, file and document sharing, and screen and image sharing and 
annotation. Rendezvous provides server “channels,” allowing large workgroups to 
share information simultaneously. Rendezvous implements GroupWare technologies 
such as shared whiteboards, shared documents, text communication rooms, collective 
browsing in a consistent work environment. Rendezvous is compatible with TCP/IP 
based networks. 

RWC (HP, SOL, NT) 

[COTS, licensed by 

VisualTek Solutions, Inc] 

The Rendezvous Whiteboard client segment is the client component of an 
Internet/Intranet Whiteboard. See RWS for additional details. 

SD (HP, SOL, NT) 

[Public Domain, no 
licensing] 

Session Directory is a multicast backbone (MBONE) application that provides (1) an 
easy way to create multicast sessions, (2) a facility to advertise new session(s) and (3) 
a dynamically updated list of available sessions (e.g., VAT audio conferences, and NV 
or VIC videoconferences). SD is used in COMPASS 98 as an alternate method for 
setting up and launching audio (VAT) and videoconferences (VIC/NV). 

VAT (HP, SOL, NT) 

[Public Domain, no 
licensing] 

Visual Audio Tool allows users to conduct host-to-host or multihost audio 
teleconferences over an Internet (multihost conferences require that the kernel support 
IP multicast). On most architectures, no hardware other than a microphone is required 
- sound I/O is via the built-in audio hardware. 

VIC (HP, SOL, NT) 

[Public Domain, no 
licensing] 

Primary video conferencing application for COMPASS 98. Video Conferencing (VIC) 
was designed with a flexible and extensible architecture to support heterogeneous 
environments and configurations. For example, in high bandwidth settings, multi¬ 
megabit full-motion JPEG streams can be sourced using hardware assisted 
compression, while over lower bandwidth environments like the Internet, aggressive 
low bit-rate coding can be carried out in software. VIC is based on version 2 of the 
Real-time Transport Protocol (RTP), which provides basic real-time media 
communication support. RTP is an application-level protocol and is implemented 
entirely within VIC -- no special system enhancements needed to run RTP. Although 
VIC can be run point-to-point using standard unicast IP addresses, it is primarily 
intended as a multiparty conferencing application. 

NV (Sun) 

[Public Domain, no 
licensing] 

Alternate video conferencing application for COMPASS 98. Network Video allows 
users to transmit and receive slow frame rate video via UDP/IP across an Internet. 

Video streams can be either sent point to point, or sent to several destinations 
simultaneously using IP multicast. Receivers need no special hardware - just an X 
display. Transmitters need some sort of frame capture hardware (e.g., Sun Video 

Card part number XI085A) 

NVAT (NT) 

[Public Domain, no 
licensing] 

Alternate video conferencing application for COMPASS 98. Network Video Audio Tool 
(NVAT) is an audio/video application for Windows 95 and Windows NT, compatible 
with NV and VAT. UsesRTPvl. 


2. System Requirements 

COMPASS has Solaris, HP and NT segments. Its additional hardware requirements are as 
follows: 

• Video Card (e.g., Sun Part # X1085A) for video transmission using Video Conferencing (VIC) 
[not required for video reception] 
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• NTSC Video Camera for video transmission using Video Conferencing (VIC) [not required for 
video reception] 

• Microphone for audio transmission using Visual Audio Tool (VAT) 

3. Users/Training 

Collaborative planners use the COMPASS application. 

4. Points of Contact 

The GCCS Program Management Office POC is Maj. Cooper (703) 735-8611. 

The GCCS Engineer POC is LCDR Otis, (703) 735-8764. 
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Common Operational Picture (COP) Embedded Training 


1. System Description 

The Common Operational Picture (COP) embedded training consists of three segments designed 
to assist GCCS users in training, generating scenarios and recreating previous tactical events. A 
short description of the functionality for the three segments follows: 

The Training (TRAIN) segment is capable of creating and conducting a broad range of training, 
from simple entry level sessions to dynamic, scenario-driven operations. It is fully embedded 
within GCCS. All GCCS functions are available and may be activated during session creation 
and playback. 

The Scenario Generator (SCGEN) allows a user to position simulated platforms on the GCCS 
map, generate movement of these platforms, annotate events and save the resulting track data in 
OTH-T GOLD replay files. These files can be replayed with the Replay option, or with the 
Reconstruction and Training modules. It is used for creating scenarios as part of GCCS 
embedded training sessions and plans, and for setting up dispositions for planning, real 
operations, live exercises and “what if’ analysis. 

The Reconstruction (RECON) segment archives data from the GCCS Tactical Data Base 
Manager (TDBM) and Communications Manager. It enables the operator to recreate past tactical 
events on an operational GCCS system and apply tactical decision aides to this non-real time 
track data. 

2. System Requirements 

COP Embedded Training runs on the SUN/Solaris 2.5.1 platform. 

3. Users/Training 

COP embedded training is for all GCCS users. A subject matter expert can quickly and easily 
build training sessions of varying complexity without any knowledge of software development 
techniques, then present them as an overlay on the standard GCCS display. 

4. Points of Contact 

The Program Management Office POC is Major Cooper, (703) 735-8611. 

The GCCS Engineering Office POC is Cindy Hopkins, (703) 735-8754. 
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Microsoft Front Page 


1. System Description 

Microsoft Front Page is a web site creation and management tool. It provides a fast and effective 
way to create and manage professional quality Internet or Intranet sites without programming. It 
makes it easy for new users and professional Web developers to build and maintain great-looking 
Web sites quickly. Front Page is a partial segment whose purpose is to validate that the 
commercial-off-the-shelf (COTS) application, Microsoft FrontPage 98, has been installed on the 
PC. The COTS product is installed using the licensed CD-ROM purchased by the site. This 
version adds the Integ directory (containing the IntegNotes and VSOutput files) and changes the 
SMEMORY value to 18 to reflect the value stated in the SVD. Microsoft FrontPage 98 

2. System Requirements 

Front Page runs on the Windows NT 4.0 operating system. The segment requires that the 
commercial off-the-shelf (COTS) product, Front Page 98, be installed on the target computer 
before the segment is installed. It the COTS software is not installed, the installation will be 
terminated. Individual services or GCCS sites are required to procure licensed copies of the 
Front Page software. 

3. Users/Training 

No training is required nor given. 

4. Points of Contact 

The Program Management Office POC is Major Partridge, (703) 735-8661. 

The GCCS Engineering Office POC is LCDR Otis, (703) 735-8764. 
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GCSS Common Operational Picture (COP)-Combat Support Enabled (CSE) 


1. System Description 

The GCSS Common Operational Picture (COP)-Combat Support Enabled (CSE) is an extension 
to the GCCS Common Operational Picture that provides access to combat support information. 
This provides the warfighter a fused tactical and combat support picture utilizing one command 
and control application. The GCSS COP-CSE makes use of the GCSS Combat Support Data 
Environment (CSDE) to access multiple combat support data sources. The GCSS CSDE consists 
of a virtual database and the GCSS Data Model. Currently, the GCSS COP-CSE via the CSDE 
accesses combat support information from the Joint Total Asset Visibility (JTAV), Joint 
Operations Planning and Execution System (JOPES), GCCS Status of Operational Readiness and 
Training Systems (GSORTS), Global Transportation Network (GTN) and National Imagery and 
Mapping Agency (NIMA) databases. Additional combat support sources will be available to 
users of the GCSS COP-CSE as they as added to GCSS CSDE in the future. 

2. System Requirements 

The GCSS COP-CSE runs on a GCCS 3.0.3 Solaris platform. Additionally, the SUNJRE 1.0.0.1 
segment is required. 

Hardware requirements: SUN workstation SPARC 20 or higher. 

Additionally, the GCSS COP-CSE must have SIPRnet access to the GCSS Data Brokering 
Environment and users of the GCSS COP-CSE must be registered GCSS users. 

3. Users/Training 

Training materials for the GCSS COP-CSE are under development by DISA. Initial training in 
the PACOM Theater will be conducted by DISA as the segments are fielded. 

4. Points of Contact 

The Program Management Office POC is Major Cooper, (703) 735-8611. 

The GCCS Engineering Office POC is LTC Merrick, (703) 735-8783. 
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GRIS Web Interface (GRISWI) 


1. System Description 

The GRIS Web Interface (GRISWI) is a Joint Mission Application Software (JMAS) segment. 

It is used by the Joint Reconnaissance Centers (JRCs) at designated Unified Command sites. 
GRISWI provides automated support in planning, scheduling, reporting, and monitoring 
reconnaissance activities under the Sensitive Reconnaissance Operations (SRO) program. 
GRISWI maintains a near real-time status of all SRO missions and provides immediate on-line 
retrieval of mission, track, and message data. To accomplish this, GRISWI provides automated 
real-time capture and processing of Reconnaissance Information Processing System (RIPS) 
format messages, and maintains a mission and track database containing schedule and resultant 
information. GRISWI generates and releases outgoing SRO messages to the Automated Digital 
Network (AUTODIN) and provides on-line query and report capabilities detailing message, 
mission status, and scheduling information. It is used to maintain current Track Dictionary data 
and to generate the master copy of each new dictionary or set of change pages. GRISWI has 
external interfaces with the GCCS Automated Message Handling System (AMHS), and the Joint 
Mapping Toolkit (JMTK). 

2. System Requirements 

GRISWI runs on the Solaris platform. 

3. Users/Training 

GRISWI is used primarily by the Joint Reconnaissance Centers at designated Unified Command 
sites. 

4. Points of Contact 

The GCCS Program Management Office POC is Beverly Walker, (703) 735-8666. 

The GCCS Engineering POC is Bob Marion, (703) 735-8578. 
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GSORTS Input 

Readiness Assessment System (RAS) Input Tool 

1. System Description 

The GSORTS RAS Input Tool provides an icon that allows GCCS users to launch a web browser 
session and connect to an NT server located at the NMCC. This enables users to create, add, 
modify, delete, and generate unit status reports as well as create and delete unit registrations. 
These requirements are specified in Joint Publication 1-03.3. The Input Tool uses web-based 
technology with near real time processing to replace the batch-processing environment currently 
used for input transactions. Thus the edits will be applied to a unit’s status report immediately. 
This ensures that a unit will receive immediate feedback on inaccuracies and incorrectly 
formatted submissions will not be accepted. 

2. System Requirements 

GSORTS RAS Input Tool runs on platforms using Microsoft Windows NT version 4.0/Service 
Pack 4 operating systems and has dependencies with other GCCS software segments. The Input 
Tool requires the Netscape Web Browser (WEBBr 4.0.3.1) and CompT. 

3. Users/Training 

The Joint Staff, J3 Readiness Division, is currently coordinating training for GSORTS RAS 
Input Tool users with the Services. Training is presently incorporated into the Users Manual. 
Embedded training is the eventual goal and will be developed. 

4. Points of Contact 

The Program Management Office POC is Major Craig Cooper, (703) 735-8611. 

The GCCS Engineering Office POC is Bob Bovee, (703) 681-2566. 
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GSORTS Output 

Readiness Assessment System (RAS) Output Tool 

1. System Description 

GSORTS RAS Output Tool is a user friendly, comprehensive query and reporting tool used to 
retrieve and analyze data from SORTS and JOPES databases. The system uses “point and click” 
technology and intuitive interfaces to help users arrange and filter data, accessing unit resource, 
training, organizational hierarchy, and commitment data. The system also has an advanced 
export capability to allow the use of a broad range of commercial off-the-shelf software for 
reporting and publishing, such as Web browsers, word processors, spreadsheets, and presentation 
software. Data received in the GSORTS RAS Output Tool is displayed in the GCCS-approved 
Web browser through a series of query screens. Users can navigate screens through a “point and 
click” procedure. The system also enhances the clarity of presenting unit readiness status 
information by color coding the displays. CINC, Service, CSA, and Joint Staff requirements 
were gathered in a series of Joint Application Development sessions. 

2. System Requirements 

The GSORTS RAS Output Tool client (RASQRY) runs on platforms using Microsoft Windows 
NT version 4.0/Service Pack 4 operating systems and has a dependency on Netscape Web 
Browser (WEBBr 4.0.3.1). 

The GSORTS RAS Output Tool server (RASSVR) runs on platforms using Solaris 2.5.1 
operating systems and has a dependency on the GSORTS client database segment GORA 
5.0.0.1, Netsite Web Server (WEBSv 1.0.0.2), and Netscape Web Browser (WEBBr 4.0.3.1). 

3. Users/Training 

The Joint Staff, J3 Readiness Division, is currently coordinating training for the GSORTS RAS 
Output Tool users with the Services. Training is presently incorporated into the Users Manual. 
Embedded training is the eventual goal and will be developed. 

4. Points of Contact 

The Program Management Office POC is Major Craig Cooper, (703) 735-8611. 

The GCCS Engineering Office POC is Bob Bovee, (703) 681-2566. 


Appendices 6-23 



JOPES Editing Tool (JET) 


1. System Description 

The JOPES Editing Tool (JET) provides a capability to create, add, modify, delete and generate 
output on deployment-related information contained in an Operation Plan (OPLANB) tie Phased 
Force Deployment Data (TPFDD). This TPFDD edit capability is a critical tool for deliberate or 
peacetime planning and time-sensitive or Crisis Action Planning (CAP). 

2. System Requirements 

JET runs on the Sun/Solaris 2.5.1 platform. 

3. Users/Training 

JET is used by the JOPES community in the Joint Staff and Unified Command staffs. 

4. Points of Contact 

The GCCS Program Management Office POC is Major Cooper, (703) 735-8611. 

The GCCS Engineering POC is Jane Davis, (703) 681-2582. 
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MAT 


1. System Description 

MAT is a medical planner’s tool that provides a requirements generator (MAT-RG) and a course 
of action analysis (MAT-COAA) module. Previously, two separate models performed these 
functions. MAT combines these two functions into a single environment and provides interfaces 
between them and to other data sources and automated tools. 

2. System Requirements 

MAT runs on the Windows NT operating system. 

3. Users/Training 

MAT will be provided to medical planners at the CINC, Service, and CINC component level. 

4. Points of Contact 

The Program Management Office POC is Major Cooper, (703) 735- 8611. 

The GCCS Engineering Office POC is LCDR Otis (703) 735-8764. 
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METOC JMS/MIS 


1. System Description 

METOC imports, processes, displays and disseminates Meteorological and Oceanographic 
products for layered overlay on the COP. It is a high-level decision aid/briefing tool as opposed 
to a forecasting tool. It provides the use of “CNN” type symbology to present environmental 
data to decision makers. Products include forecasts, warnings, gridded field data, satellite 
imagery, briefing symbology, and observations. Information is supplied on a “push/pull” basis. 
Operators can pull JMV bundles containing gridded field information, satellite (gif) information 
and observation data over the SIPRNET. Various Production, Regional and AFLOAT centers 
push to METOC. Users can also download data from various centers’ Web pages. METOC 
contains six segments. Combined, they deliver the following functionality: 

• METOC Imagery - allows viewing, animating, and management of METOC image format 
(MIF) files; overlay of static and animated imagery on the COP using JMTK. 

• METCOM Communications - allows download of OTH-T Gold format weather data from 
Fleet numerical SIPRNET website. Downloaded data can be viewed as raw grid data and 
displayed on the COP. 

• GRID Draw - allows retrieval of gridded data which can be drawn on the COP. 

• Object Plot - allows retrieval and display of environmental data, such as wind barbs, on the 
COP. 

• METOC Overlays - a draw utility which allows placing METOC symbology, text, etc., on the 
COP. These overlays can be transmitted to other GCCS sites. 

• Editors - allows creating, storing, and displaying surface and air observation data on the COP. 
Environmental Editor allows creation, viewing, editing of Bathythermographic and Ocean profile 
data and placing it on the COP. 

• Brief Utility - a PowerPoint like presentation builder which allows use of lines, text, polygons, 
pixmap and METOC symbols. It provides capability to create and annotate images, or pictures, 
and assemble them into products for electronic briefings. Graphics created can also be 
transmitted to other users. 

• METOC Status Board - a presentation tool that can be displayed on the COP. It creates 
mission scenarios with “RED/YELLOW/GREEN” assessment of the mission based on 
environmental factors. 

• METOC Data Server - Ingests and manages meteorological and oceanographic data provided 
from external sources. Provides services to METOC client applications desiring environmental 
data. 

• PARSER - Provides message parsers, or decoders, for OTH-T Gold messages. Decodes OTH-T 
Gold, GRIDFLD, RDSND, BATHY, MUNIT and NUNIT messages. 

2. System Requirements 

METOC JMS/IMS runs on the Solaris Platform. 

3. Users/Training 

METOC is used by meteorological personnel who need briefing and decision aid tools. 
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4. Points of Contact 

The GCCS Program Management Office POC is Jerry Bennett (7030 735-8282. 
The GCCS Engineer POC is Cindy Hopkins (703) 735-8754. 
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METOC Tactical Forecast System (TFS) 

1. System Description 

The METOC Tactical Forecast System (TFS) segment is a weather forecast system that provides 
communications, data management, and base weather station capabilities on a single hardware 
platform. Various newly developed weather capabilities are also incorporated in TFS, including 
communication and product distribution functionality via the World Wide Web and graphical 
red-yellow-green (go-no go) theater weather charts. Web capabilities include download of 
Appendix 30 products from remote sits for loading into the local TFS database. In addition, this 
capability allows the local user to place documents from MS Word, Excel and MS PowerPoint 
onto the local web pages as well as image files than can be downloaded from other sites or 
created locally. TFS can receive weather products from the Air Force Weather Agency and other 
remote locations using TCP/IP and HTTP. From these input data sources, the TFS develops and 
maintains, in near real-time, an in-theater weather composite data set. The TFS receives, 
displays, creates, quality controls, and transmits weather data and other related data, in deployed 
areas to C 4 I customers. The TFS mission application is composed of two software segments: (1) 
Tactical Forecast System (TFS) segment and the (2) TFS Web Application segment. 

2. System Requirements 

METOC TFS runs on the following Solaris platforms: 

• Sun SPARCstation 20 with the Turbo GX Plus graphics card running Solaris 2.5.1. 

• Sun Ultra 2 with the Creator3D graphics card running Solaris 2.5.1. 

Additionally, the TFS segment must reside on a client system (i.e., must reside on the 
workstation that the forecaster will be physically using). Each client workstation that will be 
used to run TFS must have the TFS segment physically loaded. 

3. Users/Training 

Due to the depth of expertise required to use this application, only a trained professional 
forecaster who has completed the Weather System Support Cadre (WSSC) tactical weather 
systems training course will find this application useful. 

Training for TFS applications will be made available through the Air Force Weather Agency. 

The depth of training will vary, based on individual experiences with forecasting tools. 

4. Points of Contact 

The Program Management Office POC is Jerry Bennett, (703) 735-8282. 

The GCCS Engineering Office POC is Cindy Hopkins, (703) 735-8754. 
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Microsoft NetMeeting 


1. System Description 

The Microsoft NetMeeting segment provides real-time conferencing along with several 
additional features such as communication with both audio and video, collaboration on 
Windows-based applications, exchange of graphics using an electronic whiteboard, file transfers 
and a text-based chart program. This segment is a partial segment that verifies that the Microsoft 
NetMeeting software has been installed on the PC. 

2. System Requirements 

NetMeeting runs on the Windows NT 4.0 operating system The segment requires that the 
commercial off-the-shelf (COTS) product, Microsoft NetMeeting, be installed on the target 
computer before the segment is installed. If the COTS software is not installed, the installation 
will be terminated. Individual services or GCCS sites are required to procure licensed copies of 
the Microsoft NetMeeting software. 

3. Users/Training 

No training is required nor given. 

4. Points of Contact 

The Program Management Office POC is Major Partridge, (703) 735-8661. 

The GCCS Engineering Office POC is LCDR Otis, (703) 735-8764. 
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Microsoft Office 97 


1. System Description 

Microsoft Office 97 provides a complete set of fully integrated office automation applications. 
This segment is a partial segment that verifies that the Microsoft Office 97 application has been 
installed on the PC. 

2. System Requirements 

Office 97 runs on the Windows NT 4.0 operating system The segment requires that the 
commercial off-the-shelf (COTS) product, Microsoft Office 97, be installed on the target 
computer before the segment is installed. In addition, the Software Release Packs one and two 
for Microsoft Office 97 must be installed to make Microsoft Office 97 Y2K compliant. If the 
COTS software is not installed, the installation will be terminated. Individual services or GCCS 
sites are required to procure licensed copies of the Microsoft Office 97 software. 

3. Users/Training 

No training is required nor given. 

4. Points of Contact 

The Program Management Office POC is Major Cooper, (703) 735-8611. 

The GCCS Engineering Office POC is Jeff Bognar, (703) 735-8528. 
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PC-Xware 


1. System Description 

The PC-Xware segment is an X-Windows server that enables a user to display and use X 
Window based applications on a PC running Windows NT. PC-Xware is a partial segment 
whose purpose is to validate that the commercial-off-the-shelf (COTS) application, PC-Xware, 
has been installed on the PC. This version adds the Integ directory (containing the IntegNotes 
and VSOutput files) and changes the SMEMORY value to 18 to reflect the value stated in the 
SVD. 

2. System Requirements 

PC-Xware runs on the Windows NT 4.0 operating system The segment requires that the 
commercial off-the-shelf (COTS) product, PC-Xware, be installed on the target computer before 
the segment is installed. It the COTS software is not installed, the installation will be terminated. 
Individual services or GCCS sites are required to procure licensed copies of the PC-Xware 
software. 

3. Users/Training 

No training is required nor given. 

4. Points of Contact 

The Program Management Office POC is Major Partridge, (703) 735-8661. 

The GCCS Engineering Office POC is Jaime Medero, (703) 681-2590. 
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Remote Dial-In 


1. System Description 

The AT&T STU III 1910 Driver (ATTSTU) software supports MS Windows NT remote access 
to the 1910 modem and allows for dial-up server connections from remote users. The ATTSTU 
software segment hosts the SDD1910 (aka AT&T Secure Data 1910 External Modem) driver 
software that configures the remote access dialing for modem Model(s) 1100, 2100, 4100, 
SDD1900, and SDD1910 hardware. This version of ATTSTU contains driver software that 
configures and handles Model response delays, including carrier, secure call, “failed at 14400 
retrying”, “failed at 9600 retrying”, and General Dynamics Secure Communications Systems’ 
STUN 10 Model 400/500 responses. 

2. System Requirements 

The Remote Dial AT&T STU III 1910 Driver (ATTSTU) runs on the Windows NT 4.0 operating 
system. The segment requires that the commercial off-the-shell (COTS) product, AT&T STU III 
1910 Driver (ATTSTU), be installed on a Pentium Personal Computer or higher processor. 
ATTSTU requires an AT&T STU III modem. 

3. Users/Training 

No training is required nor given. 

4. Points of Contact 

The Program Management Office POC is Major Cooper, (703) 735-8611. 

The GCCS Engineering Office POC is LCDR Otis, (703) 735-8764. 
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Rapid Query Tool (RQT) 

1. System Description 

The Rapid Query Tool (RQT) is a prototype. It consists of one segment, the RQT Client. No 
RQT specific database segment is required. It is intended to perform all the critical functions of 
legacy JOPES Ad Hoc Query (AHQ), but at a much higher speed. It is a rapid Operation Plan 
(OPLAN) query tool. It uses a new approach that provides a fast, flexible, and complete solution 
to a user’s OPLAN query needs. RQT provides a wide range of user-defined data representation 
and format options for viewing and printing OPLAN data. RQT creates a “snapshot” of OPLAN 
data through rapid retrieval using parallel processing. This snapshot is saved on the Client 
workstation and is used when generating reports. This approach allows report tailoring “on the 
fly” and greatly reduces the number of times the GCCS Oracle database is accessed. RQT 
provides the user with a comprehensive JOPES data retrieval, analysis, and output tool. The 
primary goal in the development of RQT is providing the JOPES user community with a total 
OPLAN data analysis tool with the absolute maximum performance. Speed does not come 
without the application of processing power. RQT does this by taking advantage of the database 
server’s capability to manage multiple processors and processes. RQT creates multiple 
processes to extract data, thus eliminating the time-consuming bottleneck of multiple ORACLE 
table joins. After the data is retrieved, it is then merged into a single “snapshot” for analysis. 

The multiple processes are prioritized and managed by the database server operating system in 
consideration of server demands to perform other tasks. It is to the user’s advantage that the 
operating system puts as much computing power as available to accomplish the retrievals and 
merge the data. This is done quickly and efficiently as opposed to long term, slow processes that 
tend to bog the system down. 

2. System Requirements 

RQT resides on the Solaris Platform. The installation and runtime requirements are as follows: 
GCCS Account Group (GCCS), ORACLE Client Applications (ORAC), ORACLE Client Tools 
2 (ORAT2) and TCL (TCL). 

3. Users/Training 

RQT was developed for the JOPES user community. Training will be included in the JOPES 
course by the JOPES Training Organization at Scott Air Force Base. In addition, there is 
excellent training information/examples contained in the Users Guide, CM 500-373-15, which 
can be downloaded from the DISA Homepage. 

4. Points of Contact 

The GCCS Program Management Office POC is Maj Cooper (703) 735-8611. 

The GCCS Engineer POC is Jane Davis (703) 681-2582. 
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Seagate Backup 


1. System Description 

The Seagate Backup provides the tools to perform automated backups of critical data on 
Windows NT servers. This segment is a partial COTS segment that verifies that the Seagate 
Backup application has been installed on the PC. This version adds the Integ directory 
(containing the IntegNotes and VSOutput files) and changes the $MEMORY value to 18 to 
reflect the value stated in the SVD. 

2. System Requirements 

Seagate Backup runs on the Windows NT 4.0 platform. 

3. Users/Training 

No training is required nor given. 

4. Points of Contact 

The Program Management Office POC is Major Cooper, (703) 735-8611. 

The GCCS Engineering Office POC is LCDR Otis, (703) 735-8764 
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Secret Agent 


1. System Description 

Secret Agent 3.1 is a file encryption utility containing implementations of the most secure and 
popular encryption and authentication algorithms available today. This segment is a partial 
segment that verifies that the AT&T Secret Agent application has been installed on the PC. This 
version adds the Integ directory (containing the IntegNotes and VSOutput files) and changes the 
$MEMORY value to 18 to reflect the value stated in the SVD. 

2. System Requirements 

Secret Agent runs on the Windows NT 4.0 operating system The segment requires that the 
commercial off-the-shelf (COTS) product, AT&T Secret Agent, be installed on the target 
computer before the segment is installed. If the COTS software is not installed, the installation 
will be terminated. Individual services or GCCS sites are required to procure licensed copies of 
the AT&T Secret Agent software. 

3. Users/Training 

No training is required nor given. 

4. Points of Contact 

The Program Management Office POC is Major Partridge, (703) 735-8661. 

The GCCS Engineering Office POC is LCDR Otis, (703) 735-8764. 
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Adaptive Course of Action (ACOA) 


1. System Description 

The Adaptive Course of Action (ACOA) system stores plans in a Campaign Object server so that 
plans are available at all times to operational planners at all levels of planning and at different 
geographical sites. ACOA provides a distributed collaborative environment through the 
following segments: 

Web Planner: The Web Planner consists of an integrated set of planning tools served uniformly 
from a web site that is accessible by a standard web browser. Web Planner planning tools are 
integrated at three levels, the graphical user interface level, the data representation level and the 
data service level. 

All tools in the Web Planner toolset share a common look and feel. All tools access and 
manipulate the same underlying plan data, which is stored in a common object-oriented 
architecture and served through a CORBA-based server. Plan data used by Web Planner tools is 
accessible by other applets and applications through the same distributed plan service 
architecture. 

The Dynamic Operations Planning Tool (DOPT) is a sequenced guidance tool, which takes a 
planner through the necessary steps of operational planning in an ordered manner. Through the 
DOPT, the planner inputs information, which results in the generation of standard documents 
and orders, selection of a CJTF, the selection of a course of action (COA), and the association of 
forces with a COA. 

The Course of Action Selection Tool (COAST) helps the planner to specify alternative COAs for 
a campaign, establish criteria by which to evaluate the effectiveness of the various COAs, and 
perform computations, which compare and rank the COAs according to their ability to meet the 
selected criteria. COAST screens capture the analyses performed in COA evaluation in a color 
display, which is useful for inclusion in briefs and slides, to document the decision-making 
process. 

Microsoft Office tools are integrated into the toolset for document and slide generation. 

Multicast collaboration tools provide the planner with VTC and whiteboard collaboration 
capability. Tools for force selection, TPFDD generation and scheduling are currently in 
development. 

LEIF : The Lightweight Extensible Information Framework (LEIF) is both an application and an 
open software development framework. As a Command and Control (C 2 ) and Information 
Technology application, LEIF presents a client interface to the operator. As an open framework, 
LEIF offers lightweight, client-oriented core architecture, with no required middle-tier or server 
capabilities. LEIF provides the means to collect data from various sources, combine the data 
intelligently, and display the data in various dimensions and configurations (maps, data plots, 
time plots, tables, spreadsheets, etc.). Data sources, data views and other data processing tools 
are integrated into LEIF as independently developed LEIF extensions (i.e., plug-in modules). 
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Odyssey: Odyssey is a standalone Java Application that runs independently of a browser. 
Odyssey is a method (a way of doing) and a framework (a way of thinking) when conducting 
distributed collaborative planning activities. It provides an over-arching graphical interface that 
requires little or no training but provides a powerful context in which to do strategic level 
planning. Odyssey provides general collaboration services and unlimited access to other 
electronic tools that a planner may need in the course of his/her duties. Operational personnel 
can quickly find and use disparate tools in the development of complex plans, requiring input 
from numerous sources. 

Geospatial Force Planning Tool (GFPT): GFPT provides a visual, time-phased, map-based 
planning environment for users to develop their operational plan. The system will allow the user 
to select forces and assign tasks by drawing their respective symbols on top of a digital map. The 
mapping environment is provided through integration of the LEIF and the COP. The user will 
also have the ability to select various objects/tasks and view property windows describing the 
object’s attributes. If desired, further drill-down will be possible to follow links back to the 
object’s data source. For example, if the user has selected a unit (ship, armored division, etc), the 
drill-down links will pull the unit’s home page. This will display the units GSORTS data such as 
Readiness levels. 

Virtual Situation Book (VSB)/Virtual Plan Book (VPB): VSB/VPB intelligently organizes 
and presents a condensed overview of a particular topic. The VSB/VPB makes use of advanced 
visualization formats (dynamically tailored to users) with drill-down that enable quick 
understanding of the important elements of a crisis situation. VSB/VPB is a multimedia 
container for live distributed objects (objects are connected to pertinent data sources). VSB/VPB 
objects are represented in multi-dimensional, hierarchical and multi-scale forms. Temporal 
analysis is supported. To support drill-down, VSB/VPB makes use of a Knowledge Broker 
Agent to intelligently access the repositories needed to elaborate the information shown by the 
live objects. 

Intelligent Process Manager (IPM): IPM is a foundation technology for ACOA. It consists of 
IPM/Process Design and Reengineering (IPM/PDR) and IPM/Process Monitoring and 
Visualization (IPM/PMV). IPM/PDR is a process design, verification, visualization, and analysis 
tool with multiple means for entering a process model and with email-based facilities for 
importing processes specified in Excel or ProcessScript. IPM/PMV is a collaborative process 
monitoring and visualization tool with facilities for tracking the status of individual activities and 
rolling up the individual activity status to determine the status of the parent processes. 

IPM/PDR is used on ACOA to define/capture, verify, and catalog component CAPE processes at 
multiple levels of abstraction. These component processes or process fragments are the building 
blocks for constructing process models for CAPE scenarios. IPM/PDR is being used to create a 
library of reusable ACOA process fragments (assets). This library will support the composition 
of a CAPE process model for a particular mission. The resulting model will be used by 
IPM/PMV to monitor and visualize the state and status of the overall process. It does so by 
rolling up the status of the individual activities (i.e. leaf nodes) and subprocesses from lower 
levels. 
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2. System Requirements 

ACOA runs on the Windows NT 4.0 platform. 

3. Users/Training 

ACOA is intended for use by all GCCS operational planners. Training will be embedded in the 
ACOA system. 

4. Points of Contact 

The Program Management Office POC is Maj Copper, (703) 735-8611. 

The GCCS Engineering Office POC is Bob Marion, (703) 735-8578. 
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Automated Joint Monthly Readiness Review (AJMRR) 


1. System Description 

The Automated Joint Monthly Readiness Review (AJMRR) program provides an automated 
capability supporting the Joint Staffs Joint Monthly Readiness Review (JMRR) analysis and 
brief-building process. Its objective is an expedited and accurate JMRR product to support Joint 
Staff and OSD force management and procurement issue resolution and decision making. 
AJMRR is the Joint Readiness Extension of the Advanced Joint Planning (AJP) ACTD. AJMRR 
provides the JMRR reporting community with standardized input screens, web publishing tools 
and the connectivity to exchange any type of readiness information. The system will also keep a 
database of all readiness information. This database will give users the ability to look at 
previous slides and make decisions based on past data. It will also assist users in analyzing 
trends in readiness information. 

2. System Requirements 

AJMRR runs on the Solaris platform. 

3. Users/Training 

AJMRR is used by the Joint Staff and the Joint Monthly Readiness Review reporting 
community. 

4. Points of Contact 

The Program Management Office POC is Kerry Weathington, (703) 735-8662. 

The GCCS Engineering Office POC is Bob Bovee, (703) 681-2566. 
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AMHS Message Manager (AMHSMM) 


1. System Description 

AMHSMM is a specially developed application that provides a central message management and 
tasking system. It allows the user to access AUTODIN message traffic from the GCCS NT 
platform. It is the part of AMHS that resides on GCCS. 

2. System Requirements 

AMHSMM runs on the NT 4.0 platform. 

3. Users/Training 

AMHSMM is designed to aid personnel in the performance of Automated Digital Network 
(AUTODIN) message review, generation, coordination, and release duties. 

4. Points of Contact 

The GCCS Program Management Office POC is Major Cooper, (703) 735-8611. 

The GCCS Engineering POC is Ken Fagan, (703) 735-8643. 
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COMPASS 


1. System Description 

COMPASS is a set of Government Off-The-Shelf (GOTS) and Commercial Off-The-Shelf 
(COTS) software services. COMPASS provides a non-intrusive middleware approach that 
facilitates Collaborative Planning, Modeling & Simulation (CPM&S) access as well as 
Distributed Collaborative Planning (DCP) to the Joint-Combined Arms environment. 

COMPASS allows planners using disparate mission planning systems to move between local 
planning, collaborative planning, analysis, and simulation-based rehearsal modes. COMPASS 
capabilities include a client-server architecture with session management (SMGT) tools, a shared 
overlay manager (SOM), a composite route preview (CRP) capability, COTS DCP tools, GOTS 
DCP server tools, and the ability to observe external M&S products on host C 4 I and mission 
planning systems. 


COMPS (SOL, NT) 

[GOTS] 

The COMPASS server segment is a set of four tightly integrated servers: Session 
Management (SMGT), Shared Overlay Management (SOM), Composite Route Preview 
(CRP), and Track/Simulation Management (TSM). Each of the COMPASS servers has a 
companion client library that is integrated within a modeling, planning, or simulation 
client application (e.g., GCCS, CTAPS, AFMSS, and ModSAF). These client libraries 
process remote procedure calls from the client application to their companion server in 
order to exchange modeling, planning, and simulation data with other client applications 
via the COMPASS server. COMPS also provide two applications: Server Control (for 
starting and monitoring COMPASS sessions) and Test Client (for developmental testing 
or COMPASS session monitoring). 

COMPC (HP, SOL, NT) 

[GOTS] 

The COMPASS client library segment is a set of four statically or dynamically linkable 
function libraries (SMGT, SOM, CRP, and TSM). These libraries are code-integrated 
within a COMPASS client application and process remote procedure calls from the client 
application to their companion COMPASS server in order to exchange modeling, 
planning, and simulation data with other COMPASS client applications. 

GCPA (HP, SOL) 

[GOTS] 

The GCCS Collaborative Planning Application (GCPA) is a DII COE compliant 
application that uses the COMPASS Client Fibraries (COMPC) to exchange planning, 
modeling, and simulation information with other COMPASS-capable systems via the 
COMPASS servers (COMPS). GCPA uses the DII COE Joint Mapping Tool Kit 
(JMTK), the Track DataBase Manager (TDBM), and the UB communications 
infrastructure to interface with the underlying GCCS system. Every message received 
from the COMPASS servers by the GCPA is processed and represented in some way to 
the user of the GCPA, either on the GCPA GUI or the GCCS system chart. GCPA also 
has menu options to launch multimedia applications such as audio, video, chat, and 
whiteboard. 

GCPA Patch 1 (HP, SOL) 

[GOTS] 

GCPA Patch 1 modifies the GCCS Account Group segment (after installation of the 
CVWC segment) to enable launch of the CVWC application from the main menu. 

CVWC (HP, SOL) 

[Public Domain, licensed by 

Mitre] 

Version 

The Collaborative Virtual Workspace (CVW) client segment provides an intuitive 
method for the COMPASS user to enter and leave COMPASS sessions. CVWC 
automatically launches and terminates COMPASS applications to reduce workstation 
user workload in a distributed collaborative planning environment. See also SD, an 
alternate method for launching VAT and VIC/NV. 
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CVWC Patch 1 (HP,SOL) 

[Public Domain, licensed by 

Mitre] 

CVWC Patch 1 modifies CVWC to enable launch and termination of GCPA and RWC 
as COMPASS sessions are entered or left by the workstation user. Unpatched CVWC 
launches and terminates only VAT and VIC. 

CVWS (SOL) 

[Public Domain, licensed by 
Mitre] 

Version 

The Collaborative Virtual Workspace (CVW) server segment provides a central 
administrative facility for setting up virtual conference centers and their subordinate 
sessions. Virtual conference centers and their sessions are accessed by CVWC. 

RWS (SOL, NT) 

[COTS, licensed by VisualTek 
Solutions, Inc] 

The Rendezvous Whiteboard server segment is the server component of an 
Intemet/Intranet Whiteboard. RWS allows simultaneous text sessions, drawing on a 
shared canvas, file and document sharing, and screen and image sharing and annotation. 
Rendezvous provides server “channels,” allowing large workgroups to share information 
simultaneously. Rendezvous implements GroupWare technologies such as shared 
whiteboards, shared documents, text communication rooms, collective browsing in a 
consistent work environment. Rendezvous is compatible with TCP/IP based networks. 

RWC (HP, SOL, NT) 

[COTS, licensed by VisualTek 
Solutions, Inc] 

The Rendezvous Whiteboard client segment is the client component of an 
Internet/Intranet Whiteboard. See RWS for additional details. 

SD (HP, SOL, NT) 

[Public Domain, no licensing] 

Session Directory is a multicast backbone (MBONE) application that provides (1) an 
easy way to create multicast sessions, (2) a facility to advertise new session(s) and (3) a 
dynamically updated list of available sessions (e.g., VAT audio conferences, and NV or 
VIC videoconferences). SD is used in COMPASS 98 as an alternate method for setting 
up and launching audio (VAT) and videoconferences (VIC/NV). 

VAT (HP, SOL, NT) 

[Public Domain, no licensing] 

Visual Audio Tool allows users to conduct host-to-host or multihost audio 
teleconferences over an Internet (multihost conferences require that the kernel support IP 
multicast). On most architectures, no hardware other than a microphone is required - 
sound I/O is via the built-in audio hardware. 

VIC (HP, SOL, NT) 

[Public Domain, no licensing] 

Primary video conferencing application for COMPASS 98. Video Conferencing (VIC) 
was designed with a flexible and extensible architecture to support heterogeneous 
environments and configurations. For example, in high bandwidth settings, multi¬ 
megabit full-motion JPEG streams can be sourced using hardware assisted compression, 
while over lower bandwidth environments like the Internet, aggressive low bit-rate 
coding can be carried out in software. VIC is based on version 2 of the Real-time 
Transport Protocol (RTP), which provides basic real-time media communication support. 
RTP is an application-level protocol and is implemented entirely within VIC — no 
special system enhancements needed to run RTP. Although VIC can be run point-to- 
point using standard unicast IP addresses, it is primarily intended as a multiparty 
conferencing application. 

NV (Sun) 

[Public Domain, no licensing] 

Alternate video conferencing application for COMPASS 98. Network Video allows 
users to transmit and receive slow frame rate video via UDP/IP across an Internet. Video 
streams can be either sent point to point, or sent to several destinations simultaneously 
using IP multicast. Receivers need no special hardware - just an X display. Transmitters 
need some sort of frame capture hardware (e.g., Sun Video Card part number X1085A) 

NVAT (NT) 

[Public Domain, no licensing] 

Alternate video conferencing application for COMPASS 98. Network Video Audio Tool 
(NVAT) is an audio/video application for Windows 95 and Windows NT, compatible 
with NV and VAT. UsesRTPvl. 


2. System Requirements 

COMPASS has Solaris, HP and NT segments. Its additional hardware requirements are as 
follows: 

Video Card (e.g., Sun Part # X1085A) for video transmission using Video Conferencing (VIC) 
[not required for video reception] 
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NTSC Video Camera for video transmission using Video Conferencing (VIC) [not required for 
video reception] 

Microphone for audio transmission using Visual Audio Tool (VAT) 

3. Users/Training 

Collaborative planners use the COMPASS application. 

4. Points of Contact 

The GCCS Program Management Office POC is Maj. Cooper (703) 735-8611. 

The GCCS Engineer POC is LCDR Otis, (703) 735-8764. 


Appendices 6-43 



Defense Message System (DMS) Microsoft Outlook 98 


1. System Description 

The Defense Message System (DMS) Microsoft Outlook 98 User Agent (UA) adds specific 
features to the commercial Outlook technology to comply with the specifications set by the 
United States Department of Defense (DoD). It offers messaging and groupware capabilities, 
and supports universal connectivity. DMS Microsoft Outlook 98 User Agent will be used for 
DII COE-based application segments on the Global Command and Control System (GCCS). 
This segment is an abbreviated segment for the NT-platform. 

2. System Requirements 

DMS-T Outlook 98 runs on the NT 4.0 platform. 

3. Users/Training 

For sending and receiving messages over networks. This user agent resides on the client, and 
offers FORTEZZA security capabilities (a security measure endorsed by the Department of 
Defense (DoD). 

4. Points of Contact 

The GCCS Program Management Office POC is Major Cooper, (703) 735-8611. 

The GCCS Engineering POC is Ken Fagan, (703) 7351-8643. 
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Force Module Editor (FMEDIT) 


1. System Description 

Force Module Editor (FMEDIT) is an application which can create multiple levels of 
hierarchically arranged force modules (FM) to complement the single level of FMs in TPEDIT. 
FMEDIT has the capability to expand dramatically in terms of constructing FMs based on 
attributes such as mission, capabilities, etc, which allows much improved flexibility in 
deployment planning and a tighter coupling of the employment plan and the deployment plan. 
FMEDIT is a part of the Joint Planning and Execution Toolkit (JPET) that also includes the JTF 
Map System (MATT), TPFDD Editor (TPEDIT), and Theater-level Analysis, Replanning, and 
Graphical Execution Toolkit (TARGET) software. 

2. System Requirements 

FMEDIT requires Oracle Client Applications (ORAC), FMEDIT Database (FMDATA), and 
TPEDIT Data (TPDATA) segments to be installed on the Oracle Database Server before 
installation. 

3. Users/Training 

JPET users will use FMEDIT for collaborative planning and crisis action planning. 

4. Points of Contact 

The GCCS Program Management Office point of contact is Major Cooper, (703) 735-8611. 

The GCCS Engineering Office point of contact is Bob Marion, (703) 735-8578. 
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Integrated Imagery and Intelligence (13) 


1. System Description 

The GCCS Integrated Intelligence and Imagery (13) is a tool that overlays Defense Intelligence 
Agency data, Order of Battle and targets on imagery using Joint Mapping Tool Kit (JMTK). 13 
enhances GCCS with the ability to access military intelligence imagery assets. It provides 
necessary intelligence features to the warfighter and consists of 44 segments which comprise 
several key databases and activities. Major segments and some of the key functions are as 
follows: 

• Imagery Management Database segment - provides for intelligence imagery by storing data on 
location and type of imagery 

• Navy Intelligence Database- stores characteristics and performance data for aircraft, helicopters, 
ships, submarines and missiles 

• Intelligence Database Applications - includes SQL stored procedures that enhances data retrieval 
supporting JMHS and Intelligence Mission applications 

• General Military Intelligence Database - stores order of battle, facilities and unit data 

• ICS Server - provides ability to send and receive digital imagery files over full-duplex, half¬ 
duplex and simplex communications channels 

• Intelligence Database Global Data - global configuration data for DIA’s MIDB applications 

• Message Handling Services Sybase Data Interface - provides capability to receive messages and 
store message text for later use 

• TC4IDB Aggregate - parent aggregate for a number of Intelligence Shared Data Servers 
segments. Facilitates installation of those segments 

2. System Requirements 

Integrated Imagery and Intelligence (13) is hosted on the Solaris and HP platforms. 

3. Users/Training 

Initial training will be conducted through the use of Mobile Training Teams, tailored for 13 
functionality. Lessons learned from the early CENTCOM assessment will be incorporated into 
future training. 

4. Points of Contact 

The GCCS Program Management Office POC is Bob Garland (703) 735-8936.. 

The GCCS Engineer POC is Mike Greifner (703) 681-2479. 
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Information Dissemination Management (IDM) 


1. System Description 

IDM tools and services assist in the identification and characterization of appropriate information 
and in its retrieval and delivery to appropriate users while accommodating heterogeneous 
communications networks with intermittent availability. IDM is that set of policies, procedures, 
tactics and techniques which has for its goal the provision of the “right information at the right 
place at the right time.” IDM accomplishes this by providing profiling, cataloging and search 
capabilities for network based information repositories, i.e. “smart pull.” 

2. System Requirements 

IDM runs on the Sun/Solaris 2.5.1 platform. 

3. Users/Training 

IDM users are comprised of the CINC and his Staff down to the Joint Task Force (JTF) 
components. IDM provides the capability for the warfighter and commander to determine which 
information is to be “dynamically forward deployed” (i.e., information moved into the theater 
from remote source repositories periodically and automatically based on the warfighter’s 
profile.) The warfighter profile states the information needs of the warfighter, nominally using 
metadata to describe the type of information desired (e.g., weather in Germany). The profile also 
specifies where that information should be sent and at what frequency (i.e., every 10 days, every 
8 hours). A warfighter profile may apply to an individual or group of users. Information 
searched and retrieved by IDM services can be generated in theater, at a CONUS garrison 
location, or at a national source, and can originate directly from the source generator or from a 
temporary storage or archive function. IDM allows information flow to be controlled according 
to preset priorities. This ensures that mission-critical information is provided to the warfighters 
in a timely and efficient manner. IDM users are Commanders who set information priorities and 
profiles for their AOR users and information consumers thus providing effective information 
awareness, access, and delivery to the warfighter. 

IDM training is comprised of users manuals and associated documentation as well as planned 
embedded application training methods and techniques. 

4. Points of Contact 

The Program Management Office POC is Major Craig Cooper, (703) 735-8611. 

The GCCS Engineering Office POC is Russell Smith, (703) 681-2482. 
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Joint Defensive Planner (JDP) 


1. System Description 

JDP is a mission application for preparing and evaluating Air Defense Plans. The JDP 
application allows the user to evaluate candidate defense strategies against theater ballistic 
missile, cruise missile, and aircraft attacks. Planners interact with a Graphical User Interface 
(GUI) to set up different air defense courses of action (CoAs), including alternative force 
deployments and defense priorities. Planners can evaluate air defense CoAs using analytic 
weapon- and sensor-coverage utilities, and force-on-force simulations. Optimization 
functionality may be used to produce alternative radar deployments that may subsequently be 
analyzed using the JDP analysis tools. JDP has the capability to produce and import a 
TACOPDAT message to disseminate defensive plans. 

2. System Requirements 

Sun SPARCstation 20 or better running Solaris 2.5.1 with at least 8 GB HD and 300 MB RAM. 

3. Users/Training 

The JDP application is designed to assist Theater Air and Missile Defense (TAMD) planning 
staffs of the commanders in chiefs (CINCs), Joint Force Commander (JFC), Area Air Defense 
Commander (AADC), Regional Air Defense Commander(s) (RADC), and Component 
Commanders in the development of operational level joint TAMD plans to counter air and 
missile threats. 

Training for the JDP application is available through the Air Force C 2 Warrior School, Hurlburt 
Air Force Base, Florida. 

4. Points of Contact 

The Program Management Office POC is Bob Garland, (703) 735-8936. 

The GCCS Engineering Office POC is Lt Col Merrick, (703) 735-8683. 
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Joint Forces Requirements Generator (JFRG) II 


1. System Description 

Joint Forces Requirements Generator (JFRG) II is a PC application to support remote and 
forward deployed users in generating Time Phased Force Deployment Data (TPFDD). JFRG 
provides a unit-level deployable, microcomputer-based deployment planning tool for the Joint 
community. JFRG accelerates the development, sourcing, analysis, and refinement of plans and 
deployment databases resulting in executable JOPES TPFDD. It will provide a bridge between 
JOPES and the TCAIMS II system, and reduce response time by more efficiently creating and 
refining plans that can be accomplished directly in JOPES. JFRG prepares timely initial 
estimates through the use of standard reference data and analysis tools. It facilitates 
identification of accurate unit data down to the unit personnel and Level 4 cargo detail. It 
consolidates joint and service-specific reference information and codes from numerous sources. 
JFRG can produce JOPES executable TPFDDs, a JOPES transaction file for modifications to an 
existing OPLAN database, and can download existing JOPES plans. 

2. System Requirements 

JFRG operates on an NT 4.0 platform. 

3. Users/Training 

JFRG is utilized by the joint planning community. JOPES users are not anticipated to have 
problems using JFRG and manuals will be distributed with the software. The developer will train 
the DISA (D3) Mobile Training Teams (MTTs) and the MTTs are to provide on-site training as 
required. 

4. Points of Contact 

The GCCS Program Management Office POC is Maj Cooper (703) 735-8611. 

The GCCS Engineer POC is Maj Howell (703) 735-8631. 
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Nickname, and Exercise Term system (NICKA) 


1. System Description 

The Code Word, Nickname, and Exercise Term system (NICKA) is designed to fully automate 
the OSD requirement for maintenance of code words, nicknames, exercise terms and 
reconnaissance nicknames data by the Joint Staff. NICKA maintains records of all reported code 
words and their status, all reconnaissance nicknames used at the Joint Reconnaissance Center, all 
exercise terms, and all currently authorized nicknames. The system validates code word and 
nickname usage with assigned agencies and ensures that authorized nicknames and code words 
are not duplicated. The NICKA transaction provides a way to register and maintain the currency 
of code words, nicknames, and exercise terms. NICKA uses a three-tiered architecture: client, 
server, and database. The three segments that make up NICKA (NICKO, NICKCL and 
NICKDB) are described below. NICKO has two components. One component provides all 
HTML, Java class, and script files necessary to display information to the users and accept their 
inputs from a Java-supported web browser. The other component is the server-side application 
that accepts client-provided information, uses it to query the database, and returns the resulting 
information to the client. The NICKA Online Client segment (NICKCL) is designed to provide 
the icon for the user’s GCCS Common Desktop Environment (CDE) to launch the NICKA 
Online Web Application. At the NMCC, each authorized user must be entered in the NICKA 
database before the user can access the application with the icon. When the icon is launched, the 
application validates the user and the web browser will display the initial entry screen for which 
the user is authorized to access the application. The initial screen displayed is based on the user’s 
type: retrieval (R), update (U) or maintenance (M). The NICKA Database segment 
(NICKDB) builds the NICKA Oracle tables and loads data into the tables to support the NICKA 
Online Web Application. This segment will reside on the database server at the NMCC. 

2. System Requirements 

NICKA segments are developed for the Sun/Solaris platform. 

3. Users/Training 

GCCS(T) users will include the National Command Authorities (NCA) and the CINCs. GCCS 
training coordinator and NMCC mobile training teams are currently coordinating training 
curriculum and presentation. 

4. Points of Contact 

The GCCS Program Management Office POC is Maj. Partridge (703) 735-8661. 

The GCCS Engineer POC is Jaime Medero (703) 681-82590. 
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Nuclear Weapons Contingency Operations Module Server (NWCOMS) 

1. System Description 

The Nuclear Weapons Contingency Operations Module Server (NWCOMS) provides 
summarized information regarding the status, location, and condition of U.S. nuclear weapons. 

It is made up of two segments, NWCOM and NWCOMS, the client and server respectively, and 
is part of the GCCS-T application. 

2. System Requirements 

NWCOMS is intended for the Solaris 2.5.1 Operating System running on Sun Microsystem 
servers. It requires access to the SIPRNET. 

3. Users/Training 

NWCOMS is used by Defense Threat Reduction Agency staff, Joint Staff and Unified Command 
staffs for planning and operations as required. 

4. Points of Contact 

The GCCS Program Management Office POC is Maj Partridge, (703) 735-8661. 

The GCCS Engineering POC is Jeff Bognar, (703) 73 
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Secret Agent 


1. System Description 

Secret Agent 3.1 is a file encryption utility containing implementations of the most secure and 
popular encryption and authentication algorithms available today. This segment is a partial 
segment that verifies that the AT&T Secret Agent application has been installed on the PC. This 
version adds the Integ directory (containing the IntegNotes and VSOutput files) and changes the 
$MEMORY value to 18 to reflect the value stated in the SVD. 

2. System Requirements 

Secret Agent runs on the Windows NT 4.0 operating system The segment requires that the 
commercial off-the-shelf (COTS) product, AT&T Secret Agent, be installed on the target 
computer before the segment is installed. If the COTS software is not installed, the installation 
will be terminated. Individual services or GCCS sites are required to procure licensed copies of 
the AT&T Secret Agent software. 

3. Users/Training 

No training is required nor given. 

4. Points of Contact 

The Program Management Office POC is Major Partridge, (703) 735-8661. 

The GCCS Engineering Office POC is LCDR Otis, (703) 735-8764. 
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Theater Analysis Replanning and Graphical Education Toolkit (TARGET) 


1. System Description 

TARGET is a set of applications designed to assist, in a distributed and collaborative 
environment, the employment planning process under crisis action conditions at the CJCS and 
CINC (strategic and theater/operational) levels. It is normally included as part of the Joint 
Planning and Execution Toolkit (JPET). 

2. System Requirements 

TARGET runs on Solaris and HP Platforms. The TARGET segment installation requirements 
are that Objectivity/DB (OBJECT) 4.0.10 and Perl (PERL) 5.0 are already installed. Run-time 
requirements are that Force Module Editor (FMEDIT), JTF Map System (MATT), Netscape 
Web Browser (WEBBr), Orbix (IT) 2.2c, and Applix (AST) must be installed for various 
TARGET functions to be useable. 

The user organization will be responsible for obtaining software licenses for Orbix 2.2, Oracle 
7.3.2 and Applix. 

3. Users/Training 

Sites supporting Joint Staff, Service Headquarters, Unified Commands, Joint Task Force 
Headquarters, and Service Component Commands and JPET users, for crisis action planning and 
collaborative planning, will use TARGET. 

4. Points of Contact 

The GCCS Program Management Office point of contact is Major Cooper, (703) 735-8611. 

The GCCS Engineer point of contact is Bob Marion, (703) 735-8578. 
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Appendix 6G 

The DII COE (from the I&RTS, v. 4.0) 


The DII COE originated with a simple observation about command and control systems: 
certain functions (mapping, track management, communication interfaces, etc.) are so 
fundamental that they are required for virtually every command and control system. Yet these 
functions are built over and over again in incompatible ways even when the requirements are the 
same, or vary only slightly, between systems. If these common functions could be extracted, 
implemented as a set of extensible low-level building blocks, and made readily available to 
system designers, development schedules could be accelerated and substantial savings could be 
achieved through software reuse. Moreover, interoperability would be significantly improved 
because common software is used across systems for common functions, and the functional 
capability only needs to be built correctly once rather than over and over again for each project. 

This observation led to the development of the DII COE. Although its roots are in the C 4 I arena, 
the DII COE and its principles are not unique to C 4 I. The DII COE has been expanded to 
encompass a range of other functional areas including logistics, transportation, base support, 
personnel, health affairs, and finance. All new Defense Information Systems Agency (DISA) 
systems are being built using the DII COE while existing DISA systems are being migrated to 
use the DII COE. The Office of the Secretary of Defense (OSD) has recently issued a directive 63 
that requires JTA compliance and, indirectly, use of the DII COE. 

A significant aspect of the COE challenge is to strategically position the architecture so as to be 
able to take advantage of technological advances. At the same time, the system must not sacrifice 
quality, stability, or functionality already in the hands of the warrior. In keeping with current 
DoD trends, the COE emphasizes use of commercial products and standards where applicable to 
leverage investments made by commercial industry. 

A Brief History of the DII COE 

Initial DII COE development was driven by a near-term requirement to build a suitable World- 
Wide Military Command and Control System (WWMCCS) replacement. To achieve the near- 
term WWMCCS replacement objective, technical experts and program managers from the 
Services, intelligence community, Defense Mapping Agency (DMA), and other interested 
agencies met for several months beginning in the fall of 1993. Participants proposed candidate 
systems as a possible starting point for a COE architecture or as a suitable candidate for 
providing capabilities to meet WWMCCS replacement requirements. None of the candidate 
systems met all requirements, but it was clear that a combination of the “best” from several 
systems could produce a near-term system that would be suitable for WWMCCS replacement. 


62 The acronyms “DII COE” and “COE” are used interchangeably throughout this document. Other COEs have been 
created in the past (such as the Joint Maritime Information System (JMCIS) COE), which were very similar in 
scope or implementation with the DII COE. To avoid confusion, unless otherwise indicated, “COE” always refers 
to the DISA DII COE. 

63 OSD Directive dated 22 August 1996 (Subject: Implementation of the DOD Joint Technical Architecture). The 
directive states: all new C4I systems and other systems that interface to C4I systems shall be in compliance with 
the JTA. The JTA in turn mandates use of the DII COE. The JTA is being expanded in scope to address weapons 
systems as well. 
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Moreover, an infrastructure could be put into place and a migration strategy defined to preserve 
legacy systems until migration to the intended architecture could be realized. 

The cornerstone architectural concept jointly developed during that series of meetings was the 
Global Command and Control System (GCCS) COE. This initial COE was limited in scope to 
address the immediate C 4 I problem (i.e., WWMCCS replacement), but its principles, structure, 
and foundation deliberately went far beyond just the C 4 I mission domain. The GCCS COE was 
composed of software contributed from candidate systems evaluated by this original Joint 
engineering team. 

An initial proof-of-concept system, GCCS 1.0, was installed in early 1994 at one site to validate 
the approach and to receive early feedback. GCCS 1.1 followed in the summer of 1994 and was 
the first attempt to integrate software from Service programs as initial GCCS COE components. 
GCCS 1.1 included mission applications from other programs operating in a “federated” mode. 
That is, the mission applications were integrated together so as to be able to run on the same 
hardware without interfering with each other, but not yet able to effectively share data between 
applications. GCCS 1.1 was installed and tested at beta sites and used at certain operational sites 
to monitor events during the 1994 Haiti crisis. GCCS 2.0 fielding began in early 1995 at a 
number of operational sites. GCCS 2.1 was fielded in mid-1995 and by mid-1996 had 
successfully replaced WWMCCS. A prototype version of GCCS 2.2 was the basis for the 1995 
Joint Warrior Interoperability Demonstration (JWID 95) and a refinement of it was the basis for 
JWID 96. Another GCCS 2.2 enhancement was placed in theater to support Bosnia operations 
and for contingency planning when tensions in the Gulf area increased in mid-1996. 

In mid-1995 technical experts met under DISA guidance to expand the GCCS COE into the DII 
COE. The DII COE was then expanded to address other mission domains. Much of the original 
software has been updated to take advantage of further technological advances and Co mm ercial 
Off-the-Shelf (COTS) software has replaced some of the original Government Off-the-Shelf 
(GOTS) components. From this historical perspective, the GCCS COE can be viewed as a subset 
of the much larger DII COE. Although GCCS succeeded in replacing the aged WWMCCS, it is 
important to realize that GCCS is far more than just a WWMCCS replacement. 

In 1996, the Air Force Electronic Systems Command (ESC) at Hanscom AFB began exploring 
the applicability and viability of DII COE concepts to real-time systems. In the spring of 1997, 
based upon exploratory work begun at ESC, representatives from the Air Force, Army, and Navy 
met to discuss the high correlation of real-time requirements across the services. In July 1997, 
the Air Force, Army, Navy, and Marine Corps jointly petitioned DISA to charter a DII COE 
Real-time Technical Working Group (TWG). The objective of the TWG would be to develop a 
set of co mm on requirements and recommendations for potential products to provide real-time 
capabilities, thus expanding the scope of the DII COE to include real-time systems. DISA 
approved the Services’ request, and the Real-time TWG began meeting in August 1997. It is 
anticipated that real-time services will be included in release 5.0 of the DII COE, and will be 
included in the next major release of the I&RTS. 

The DII COE has its roots in command and control, but the principles and implementation 
described in this document are not unique to, nor limited to, command and control or logistics 
applications but are readily applicable to many other application areas. The specific software 
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components selected for inclusion in the COE determine the mission areas that the COE can 
address. 

The DII COE Concept 

The DII COE concept is a new approach that is much broader in scope than software reuse. Most 
software reuse approaches to date have proven less than satisfactory. Reuse approaches have 
generally emphasized the development of a large software repository from which designers may 
pick and choose modules or elect to rebuild modules from scratch. It is not sufficient to have a 
large repository, and too much freedom of choice leads to interoperability problems and 
duplication of effort. This rapidly negates the advantages of software reuse. 

Software reuse strategies have also ignored the importance of data reuse. The approach has 
traditionally been to encapsulate data into a relational database from which applications may 
retrieve the data according to their own view (i.e., schema). While this approach was a 
tremendous advance, it fell short of the goal of providing truly interoperable systems in the Joint 
arena. What is required is an approach that promotes data sharing within systems and between 
systems. The approach must also recognize and resolve the issues of duplicative data, 
inconsistencies in the data, and data replication. The Shared Data Engineering (SHADE) 
component is the data reuse strategy for the DII COE. 

The DII COE emphasizes both software reuse and data reuse, and interoperability for both data 
and software. But its principles are more far-reaching and innovative. The COE concept 
encompasses: 

• An architecture and approach for building interoperable systems 

• A minimal but extensible security architecture and a set of security services 

• an environment for sharing data between applications and systems 

• An infrastructure for supporting mission-area applications 

• A rigorous definition of the runtime execution environment 

• A reference implementation on which systems can be built 

• A collection of reusable software components and data 

• A rigorous set of requirements for achieving DII compliance 64 

• An automated toolset for enforcing COE principles and measuring DII compliance 

• An automated process for software integration 

• An approach and methodology for software and data reuse 

• A set of Application Program Interfaces (APIs) for accessing COE components 

This document is an engineering specification that describes how modules must interact in the 
target system. System architects and software developers retain freedom in building the system, 
but runtime environmental conflicts and data conflicts are identified and resolved through 
automated tools that enforce COE principles. An important side effect is that traditional 
integration tasks largely become the responsibility of the developer. Developers are required to 


64 The term “DII compliance” is preferred instead of “COE compliance” and is used throughout the I&RTS. The 
compliance concept and approach has not changed, but compliance is measured for segments within the COE as 
well as mission-application segments that lie outside the COE. Therefore, “DII compliance” is more descriptive 
and correct than “COE compliance.” 
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integrate and test their software with the COE prior to delivering it to the government. This 
simplifies integration because those who best understand the software design (the original 
developers) perform it, it reduces the cost because integration is performed earlier and at a lower 
level in the process, and it allows the government to concentrate on validation instead of 
integration. 

The COE must be understood as a multi-faceted concept. Understanding how the many facets 
interact is important to appreciate the scope and power of the DII COE and to avoid confusion in 
understanding COE material. The next subsections deal with four specific facets in more detail: 

• The COE as a system foundation 

• The COE as an architecture 

• The COE as a reference implementation 

• The COE as an implementation strategy 

Failure to understand these facets will lead to confusion and non-compliant systems. 

The DII COE as a System Foundation 

The DII COE is not a system; it is a foundation for building systems. Figure 6G-1 is a simplified 
diagram that shows how the DII COE serves as a foundation for building multiple systems. 
Details such as specific COE components, databases, and the internal structure of the COE have 
been omitted for clarity. Chapter 2 provides this level of information and describes the COE in 
much more detail. The purpose of Figure 6G-1 is to introduce the concept. 

The large outermost shaded box in Figure 6G-1 shows two types of reusable software: the 
operating system and COE components. For the present discussion, it is sufficient to note that 
COE components are accessed through APIs and that the COE components form the 
architectural backbone of the target system. The API is the means through which a system 
permits a programmer to develop applications through interaction with the underlying COE. 
Standards ( POSIX [Portable Operating System for Information Exchange ] in the diagram) and 
specifications ( TAFIM [Technical Architecture Framework for Information Management ], JTA 
[Joint Technical Architecture ], I&RTS [Integration and Runtime Specification ], and User 
Interface Specification [f/AS] in the diagram) dictate how COE components are to be built and 
how external components must be built to be compliant with the COE architecture. 
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COE Based Systems 
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Figure 6G-1. Dll COE and COE-Based Systems 


Building a target system includes combining COE components with mission-specific software. 
The COE infrastructure manages the flow of data through the system, both internally and 
externally. Mission-specific software is mostly concerned with requesting data from the COE 
and then presenting it in a form that is most meaningful to the operator (e.g., as a pie chart, in 
tabular form, as a graph). The COE provides the necessary primitives for such data whether it is 
stored locally, or whether it is accessed remotely across a Local Area Network (LAN) or Wide 
Area Network (WAN). This frees the system designer to concentrate on meaningful data 
presentation and not on the mechanics of data manipulation, network communications, database 
storage, etc. 

There is only one COE regardless of the target system. The COE is a set of building blocks. 
System designers select those building blocks (e.g., COE components) required for their mission 
application, while excluding building blocks that are not required. Each derived system uses the 
same set of APIs to access common COE components, the same approach to integration, and the 
same set of tools for enforcing COE principles. For common functions (e.g., communications 
interfaces, dataflow management), each target system uses precisely the same COE software 
components. Compliant systems do not implement their own versions of algorithms within the 
COE because this will rapidly lead to interoperability problems as algorithms are interpreted 
differently or because systems fail to upgrade algorithms at the same time. This approach to 
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software reuse significantly reduces interoperability problems because if the same software is 
used, it is not possible to have two systems that interpret or implement standards differently. 

The DII COE as an Architecture 

The DII COE is a network-centric 65 “plug and play” open architecture, presently designed and 
implemented around a client/server model. Functionality is easily added to or removed from the 
target system in small manageable units called segments. Segments are defined in terms of 
functions that are meaningful to operators, not in terms of internal software structure. Structuring 
the system into segments in this manner allows flexibility in configuring the system to meet 
specific mission needs or to minimize hardware requirements for an operational site. Site 
personnel perform field updates by replacing affected segments through use of a simple, 
consistent, graphically oriented user interface. 

The DII COE model is analogous to the Microsoft Windows® paradigm. The idea is to provide a 
standard environment, a set of standard off-the-shelf components, and a set of programming 
standards that describe how to add new functionality to the environment. The Windows 
paradigm is one of “federation of systems” in that properly designed applications can coexist and 
operate in the same environment. But simple coexistence is not enough. It must be possible for 
applications to share data. The DII COE extends the Windows paradigm to allow for true 
“integration of systems” in that mission applications share data at the server level. 

Federation versus integration is an important architectural distinction. However, integration is 
not possible without strict standards that describe how to properly build components to add to the 
system. This applies equally to software functions and data. This document and other related 
documents detail the technical requirements for a well-behaved, Dll-compliant application. The 
COE provides automated tools to measure compliance and to pinpoint problem areas. A useful 
side effect of the tools and procedures is that software integration is largely an automated 
process, thus significantly reducing development time while automatically detecting potential 
integration and runtime problem areas. 

More precisely, to a developer the DII COE includes each of the following: 

• An Architecture 66 : A precisely defined TAFIM and .//’. l-compliant architecture for how system 
components will interact and fit together and a definition of the system-level interface to COE 
components. 

• A Runtime Environment: A standard runtime operating environment that includes “look and 
feel,” operating system, and windowing environment standards. Since no single runtime 
environment is possible in practice, the COE architecture provides facilities for a developer to 
extend the environment in such a way as to not conflict with other developers. 


65 The COE is truly network-centric in its design and current implementation. Fielded COE-based systems are 
typically designed to take advantage of this fact. However, additional development is required to provide all the 
tools that would be useful to fully support a network-centric system. 

66 Th eJTA describes three types of architectures: operational, technical, and system. The DII COE is relevant to all 
three types but does not and cannot provide a complete architectural definition for all three types. For example, 
the operational architecture also includes consideration of the command echelon and reporting structure. This is 
dictated by policy and is thus outside the scope of the COE. The DII COE is limited to addressing those aspects 
of an architecture that can be implemented in hardware and software as dictated by higher level standards, 
concept of operations, and service doctrine. 
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• A Data Environment: A standard data environment that prescribes the rules whereby 
applications can share data with other applications. 

• A Reference Implementation: A clearly defined set of already implemented, reusable functions. 
A set of reusable software and data is a cornerstone of the DII COE product. 

• A Set of APIs: A collection of interfaces 67 for accessing COE components. Thus, the COE is a 
set of building blocks in the same sense that X Windows and Motif are building blocks for 
creating an application’s Graphical User Interface (GUI). 

• A Set of Standards and Specifications: A set of rules that describe how to use the COE, how to 
construct segments, how to create a GUI, etc. 

• A Development Methodology: A process for developing, integrating, and distributing the system 
and a process for sharing components with other developers. The COE emphasizes and 
encourages incremental development that has the advantage of quickly producing usable 
functionality. 

The DII COE as a Reference Implementation 

The COE necessarily includes an implementation of the components defined to be in the COE. 
The reference implementation is the key to reusability and interoperability. Use of the reference 
implementation provided is required to assure interoperability and is therefore a fundamental 
requirement for DII compliance. The reference implementation may change over time to take 
advantage of new technologies or to fix problem reports, but improvements are introduced 
incrementally while preserving product stability. 

The term reference implementation should be properly understood in the context of the DII COE. 
It means that a single body of code has been used as a starting point for implementing the COE 
on a specific hardware platform and operating system. The only differences in the actual 
executable binary code are those that arise purely as a result of porting from one platform to 
another. The algorithms and the way the algorithms are implemented are identical from platform 
to platform. 

The DII COE as an Implementation Strategy 

The COE is also an evolutionary acquisition and implementation strategy. This represents a 
departure from traditional development programs. It emphasizes incremental development and 
fielding to reduce the time required to put new functionality into the hands of the warrior, while 
not sacrificing quality nor incurring unreasonable program risk or cost. This approach is 
sometimes described as a “build a little - test a little - field a lot” philosophy. It is a process of 
continually evolving a stable baseline to take advantage of new technologies as they mature and 
to introduce new capabilities. But the changes are done one step at a time so that the warfighters 
always have a stable baseline product while changes between successive releases are perceived 
as slight. Evolutionary development has become a practical necessity for many development 
programs because the traditional development cycle time is longer than the technical 
obsolescence cycle time. This approach allows program managers the option of taking advantage 
of recently developed functions to rapidly introduce new capabilities to the field, or of 


67 The term “API” is used in the DII COE context to refer to any well-defined interface between components. It may 
refer to a C function call, a data file format, a callable executable program, etc. 
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synchronizing with COE development at various points for those situations where incremental 
upgrades are not readily acceptable to the customer community. 

The COE implementation strategy is carefully structured to protect functionality and data 
contained in legacy systems so that over time they can migrate to full COE utilization. Legacy 
systems must use only “public” APIs and migrate away from use of “private” APIs. Public APIs 
are those interfaces to the COE that will be supported for the life cycle of the COE. Private APIs 
are those interfaces that are supported for a short period of time to allow legacy systems to 
migrate from unsanctioned to sanctioned APIs. All new development is required to use only 
public APIs and use of any other APIs results in a non-DII compliant segment. 

From the perspective of a system developer, whether developing a new application or migrating 
an existing one, the present DII COE implementation is an open client/server architecture that 
offers a collection of services and already-built modules for mission applications. Thus, the 
developer’s task is to assemble and customize 68 existing components from the COE while 
developing only those unique components that are specific to particular mission’s requirements. 
These additional mission-unique components must still adhere to the standards specified in the 
JTA and this document. In many if not most cases, this amounts to adding new “pull-down menu 
entries and icons.” 

Lessons Learned 

The COE as the embodiment of an architectural concept offers the opportunity to leverage a 
mature, proven, field-tested software base for a wide variety of applications for the services, 
agencies, and Joint community. As budgets shrink and as budgetary priorities shift, program 
managers require the ability to continue to respond rapidly with systems that satisfy the 
information needs of United States and Allied Armed Forces. The COE implementation strategy 
is a significant advancement in fulfilling this ongoing need. 

Examination of state-of-the-art development in light of these realities results in a set of 
fundamental tenets that greatly influence the history, future, and direction of the DII COE. An 
explanation of these tenets is useful in understanding the COE as a whole. 

• Pre-COE practices lead to development and redevelopment of the same functionality across 
systems. Redevelopment is frequently necessary because of technological changes as algorithms 
are improved or as hardware becomes faster and cheaper. However, development cost tends to be 
high due to a lack of coordination between programs that share common requirements. 

• Security must be designed into the architecture. The increasing importance placed upon 
system security has underscored the need to view security as an engineering discipline. Security 
considerations must be addressed throughout the entire system life cycle from requirements 
analysis through maintenance. It is not sufficient to “add security” after fielding or even after 
development. 

• Duplication of functionality within the same system is more expensive than avoiding 
duplication. Lack of coordination between program developers is a fundamental cause for 


68 Customization is achieved in two ways: by omitting COE components that are not required and by configuring 
operational characteristics of the selected COE components. Customization does not mean the ability to change 
the functional operation of the component (a) outside the configurable items provided by the component or (b) 
outside the facilities provided by the component’s APIs. When customizing the COE is discussed in this 
document, it must be understood in this context as a way of tailoring the COE to meet a specific mission need. 
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duplicative functions, but an additional factor is that reuse libraries are not commonly available. 
The impact of duplication is more than just program costs. When functionality is duplicated, 
system users are often given conflicting information even in the presence of identical data 
because designers took slightly different approaches to solving the same problems or made 
slightly different assumptions. 

• Interoperability is not achievable through “paper” standards alone . 69 Standards are 
necessary, but not sufficient, 70 to guarantee interoperability. Interoperability problems are 
generally not caused by the standards chosen but by differing or incorrect interpretations of 
standards. System designers often choose different standards with which to comply, but even 
when the standards are the same, different interpretations of the standards can greatly change the 
way the resulting system operates. The COE emphasizes use of industry and government 
standards, but relies even more on automated ways of measuring and evaluating compliance, and 
thus quantitatively evaluating program risk. The only practical way to achieve interoperability is 
to use exactly the same software, written to appropriate standards, for common functions across 
applications. For example, the COE contains a common tactical track correlator to ensure that all 
users see the same tactical picture. The answer produced by the correlator may be incorrect but a 
problem correction in one place then becomes effective for all users. 

• Pre-COE practices lead to exponential growth in testing and associated development costs. 

Lack of commonality and modularity in system building blocks means that there is much 
duplication of effort in testing basic functionality and testing in one section of a system is often 
tightly coupled to testing in another section. This complicates and extends the certification 
process. Configuration management, system integration, and long-term maintenance are also 
more complex and costly when there is a lack of commonality and modularity in system building 
blocks. 

• The importance of training is usually underestimated and the magnitude of the training 
problem is increasing. An operator is often expected to use multiple systems that behave 
completely differently, are equally complex with their own subtleties, and that give slightly 
different answers. Operator turnover is rapidly reaching the point where the time it takes to train 
an operator is a significant portion of the time that the operator is assigned to his current tour of 
duty. Training is greatly reduced by a consistent “look and feel” and by the ability to present to 
the operator only those functions useful for the task at hand. 

• Don’t reinvent the wheel. If a component already exists, it should probably be utilized even if 
the component is not the optimum solution. Almost any module can be improved but that is rarely 
the issue. Reuse of existing and proven software and data structures allow focus of attention on 
mission uniqueness. Rather than concentrating scarce development resources on recreating 
building blocks, the resources can be more appropriately applied to configuration and 
development of functionality and data structures that are not already available. 

• Utilize existing commercial standards, specifications, and products whenever feasible. The 

commercial marketplace generally moves at a faster pace than the military marketplace and 
advancements are generally available at a more rapid rate. Use of commercial products has 
several advantages. Using already built items lowers production costs. The probability of product 
enhancements is increased because the marketplace is larger. The probability of standardization is 
increased because a larger customer base drives it. 


69 This statement is not meant to minimize the importance of standards, but to state that they alone are not sufficient 
to solve interoperability problems. The situation would be far more desperate in the absence of standards. 

70 The solution provided by the COE is to define specifications and a reference implementation of a standard. For 
example, in the user interface area, Motif is the standard selected for UNIX platforms and the User Interface 
Specifications for the DII is the specification written to be compliant with Motif, but tailored for the particular 
mission domain. 
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Requirements and Objectives 

The following requirements apply to the DII COE: 

• The DII COE will be fully compliant with the JTA 71 . Standards defined within the JTA promote 
an open systems architecture, the benefits of which are assumed to be well known and generally 
accepted. 

• The DII COE is intended to be hardware independent and operate on a range of open systems 
platforms running under standards-based operating systems. Program-driven requirements, 
associated testing costs, and funding will dictate which specific hardware platforms are given 
priority. 

• Non-developmental items (NDIs), including both COTS and GOTS products, are the preferred 
implementation approach. 

• The DII COE is programming-language neutral. It does not state a preference of one language 
over another, but leaves the selection of a programming language to higher-level standards profile 
guidance and programmatic considerations. Any statements in the I&RTS which appear to state 
or imply a preference for one language over another are unintentional. 

COE development is driven by C 4 I for the warrior requirements as articulated by the services 
through the appropriate DISA Configuration Control Board (CCB) process. Development 
priorities are established by the CCB Chair and given to the DII COE Chief Engineer for 
implementation. 

The broad program drivers for the DII COE lead to a number of program objectives that include 
those stated in the TAFIM, Volume 2\ 

• Commonality: Develop a common core of software that will form the foundation for Joint 
systems, initially for C 4 I and logistics systems. 

• Reusability: Develop a common core of software that is highly reusable to leverage the 
investment already made in software development across the services and agencies. 

• Standardization: Reduce program development costs through adherence to industry standards. 
This includes use of commercially available software components whenever possible. 

• Engineering Base: Through standardization and an open architecture, establish a large base of 
trained software/systems engineers. 

• Training: Reduce operator training costs and improve operator productivity through enforcement 
of a uniform human-machine interface, commonality of training documentation, and a consistent 
“look and feel.” 

• Interoperability: Increase interoperability through common software, common data structures, 
and consistent system operation. 

• Scalability: Through use of the segment concept and the COE architectural infrastructure, 
improve system scalability so that COE-based systems will operate with the minimum resources 
required. 

• Portability: Increase portability through use of open systems concepts and standards. This also 
promotes vendor independence for both hardware and software. 


71 JTA replaces some of the standards guidance in the TAFIM as per OSD directive (Subject: Implementation of the 
DOD Joint Technical Architecture) dated 22 August 1996. It replaces those standards for service areas defined 
within the JTA. For those service areas not included in the JTA , guidance in Volume 7 of the TAFIM is to be 
followed. 
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Security: Improve system security to the extent possible to protect the system from deliberate 
attack and prevent unauthorized access to data and applications. 

Testing: Reduce testing costs because common software can be tested and validated once and 
then applied to many applications. 
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t .. The success of the Expeditionary Aerospace Force 
ultimately will rest on the Air Force's ability to sustain it. 
Agile Combat Support provides commanders Improved 
responsiveness, mobility, and sustainability of their 
forces 

+ .. Information technologies, such as the Global Combat 
Support System, featuring both new leading-edge 
capabilities and technical refreshment of existing 
systems, are key to Agile Combat Support.... 

—(Senerai Michael 1L Ryan 

Chief af Staff, ihiited States Air Force 


—■Htnittrahle f L Whitten Peters. 
Secretary of the Air Fares 


Appendices 6-71 




The to implement the 

recommendations. The EAF conoepl 
depends on an integrated GCSS-AF. 
The Chief Information Officer can 
provide the appropriate impetus, and 
technology is now an enabler rather 
lhan a limiting fader. 


Appendices 6-72 






T he-Chid In formal Kin Glficcr {CfO| govo Ihc Global Cambal Support System 
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agreement among various lunclional organizations lo adept an enterprise view of 
combat -support informal on Tho lash is important because tho Expeditionary 
Aerospace Force (EaF) concept rains on integrated syslcms that provide timely, 
accurate and trusted information to tho deployed Ar Expeditionary Force iAEF) 
commander across tho spectrum of miliary operations. 

We worked the problem hard dedicated subject matter experts pooled Ihoir 
collective a*pe nonce lo provide the recommend at ms n this report. Each contributed 
to the final product each should bo proud d that contribution 
Tho combat support process has evolved ihroughout tho yoais with many tcndcnal 
erganzabens providing a pieced a very large enterprise. Functional communities ate 
performing quality work to improve their processes and modernize their systems. Whio 
everyone supports I ha noad for mtogralcd information to scpporl the warfighter, tho 
different organizational ahemalives ware appeakng m varyng degrees to various 
agonens. It was impossible lo buld unanimous agroomerri for oir recommendations 
consensus was difTiauk bul achievable. 

We baliova tho bmo phased approach rooommendod provides the best afcemaliva 
lor achioxing tha vision d a GCGG AF capabla of support ng EAF deployments- and 
operations. In Iho near tonri, we believe a □iroelor lor GCGG AF and EEhEC s required 
lo begin impte mental ion of the recommend a I ions. Uftmalefy we believe- tha Aerospace 
Command and Control Intelligence, Surveillance, and Reconnaissance Center 
(A£2 (SkC| should load this effort for our Air Force because d its warlighling locus, 
exporienoa with experimorriabon, and I ha inevitable integration between Iho Global 
Command and Control System (GrCCG-i and GCGG- Our recommend a I ion lully supports 
Iho Jorri GCSo program and postures tha Air Force bo be a loader m oombal support 
systems development 

—BID BELL, Brig ffen. IWAF 
Chii’f, 0C$S'AF ReqHiremettix 
[niegratitm Tiger Teem (GfUTT) 
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iNlceJ Ehr£4>!iiiwiii|i i i|wifliiny: 

r lliiw nu-ny p*wJskiJi-a*JdtJ munrilniu do tw- have in reii-neV 
r Wlitrt Ait lhi-y Jwiud—uin cm iJity nwwV 
• Whdl Jx i lirli -i;>iMjltl >iLiV<<iil l.:iii'jtba? 
i AI Ihevarctril jiw •idtxpi-ii4N*rf^liejidc'ii-rprvJrfHi> nia 
bill? 

■ Whj.1 siirte-cypukh iliKTt ikt niyautuiliim- pittum? 

« Wu ■iiL-£|iriiJ^d iiiwniuilcloii rf/ski l-iI Jnco clit lavtnlnn.- 
L<>ri[r<>l h;. .k iii j_il kcroim Il-iI far? 

Since car cujkjie x^k-jti* did me provide- ■ way la ihl-m, 
IvlL-^rAEt, ar prewnJ IIuk iMfnrmAEicMi, dit Hppiiri wiirlil itin-.-d hi 
brace tenet (phone ciLh, e-uuLk, tnd |y la yji j Ik-mpl lo 
aih-iuhleyad verity Ihftcritilrbl liifurjiiiElon. Om leadership Jose 
c-aufldL-atL- Ln 1 lie Jafc nail dn n lit lap. prnvided. Utbpunx 
rmpkiyiik.-ir deck hi as nrrr lin|i jcIl-U. 


We con. do tatter. 
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GCSS 

background 


G |C£S-AF|t.g L-tr-Jl L-I Iki Ac Fcuv 

t^iLic. -ii-.jLpjinr: ill ii>. in im^<. 
Ihs- Air jstriL Mil-crikl t.’ciiiiLJiid 

:aFM|' is j> I:ib 1 ia 1 tL" uuilcuidh: bur-I intT 
uHcaSliiii :y,-Jlhj-. k IUi cuie riir. uhki lL- 
Ixuc-I.vi d ^IviIljii .V.i-ii-iiirrii'E. -|BLftX1 1 
pruirau. Ib/An Fcnv hfacili Si^khI CubbuiL 
ll'cjlrul <'’£■ 11_L 3 1111i jI CuiLpjIcr. uid 

liiuI iivIke it'll i AjeLJi/lIlt-j Ctwcil .lcilific-:l 
Io-.-jii.-.il iilLTirH-rl'iliiy imcietcjieeJi I'd b^«l 
fm:!iii. f:n iitphuiLi !:4im. 
u it _ 

b IGM, W SM *:tioiJunl^^K.Al : kk 

■c-ehueJuiI vtilL Jii-.v"k:i: [tub llic i.HTIee (iT llw 
Sdcrtfarr i'f Ihfiih (OtU l In Si iidi. 'jr A-j 
Fihlv :-I.''k'ciL'i -.-■IjHi.- ltd lb: QC^-aF ^ydui. 
Piu^ibi Uflfiit (SfOF :f. ElidnuK JviIcili 
I tnlii a itSt i Milliard SiikLii □ rurp i SS>(j|. 
I L.' iVi Rini: Dr-fiamJc uI''. -:iuiiji l Ji.-ic-..i i.I 
iidcnitf in. lAr-St'i LMCiMk- ltd- 1 rail Sn >. i >. * K. - 
AF. The OmI'SS aF lciiIi Jt' v :u aVeniri in 
Dii^B<kia lijM-le LuLihcCd klirlin FuJizil 
SfilcBi. 'A im. llic Amu®! (liicl'i jftjflf J« trkd 
ikiiijcAoJ :c- "jc <jt?!K fucLliiujJ (■■.i'-jikuI. Ik- 
I liicfuf bL 4 c riczc ICSAF} jinul llw 

iJuciiy < lik^cf Hfcifl. IidIjIIjIi/i- u<I Lj^lui 
:aF if. I lb: lu u 1 ill id jrtfuiEd fie ttC. tfS-Ah . 

b Jdy HAT, AF.-IL-aribtlcJiKlllhMjRtt-AF 
L*ucnJiijlbr( 'inciil. j L-c.ii.iaJ ullku iiiiipri lli 


Tbi I'cibi-M Ini lilt- ncuilJ llhi QL'fifi.A- 
IkcaaiulT ;i■ liI:t>. he i; Lk-iuIIie napuailiihiy. 
jUliL-zilv. iL-:ic.:iii^hdV::l :i yjLL-uafj. 

ItrMifr |rdi Iv (:( SS-aF. b $LYva ibu- IWT. 
ESC Itteptiud did iiihnrfed At GCSS-AF 
i-itiUiibiii, SKJb.:iLainl (ItMlkMll 
nrcar. uid tliaagiiip iIil-ji Ic InuUui :il:I 
jiLKbiiii.ee iy-.»Eifcd. Al :l_> pcinl, £H?£S-AF 
:lvjii.e a mu.i-pl Hb! SCn'Ccjty i:fLci ILil i 
■T'BldU. TIh SSuJd'llllllLMN l.'lilll.HI I M.J> 
£B&Ulll MJi lull jd lu ikl L'.up :iul UI|U[ 1 
CHIIBLTCUI UlT-lItt^tuir. lIcICJIL’ JllV'lllljlil'j 
bI:uIiii:Iiiil ■.'ciinii'A-cpciMiui'-Liiij ^ibc iI 
tACUft-AK idi^cjlicli lli’kic'j :ik. 

AiijLiilirB uuciiilr T :: ’.hji UiSiVd^i 
pnjin ■ i u ii:t- >j'. l bclnccj :'ii Air ric:c |<-.-l-ib 
iiLTilLvc "ITillt iPEjOl lu: ki^ilhdlf^uij and 
lie .k^LiijIcin.-ijLmc'-j LiiBetikiiT fw Bud uT 
lie ruiiidiii avaJEua. ji ullilbn sruit indtib. 
here Jri Llnpc:l ud inaul:iiiih-.l ciilr iir Mil- 
duhiuilAii FuHdijHihuL^JL 

Kd ibpL ikpuiriuiE. » ‘ji c^i:I iiiliiek- 
i:lcu'i: rmii-fuEcliuicil :l--.iiii :il-:l'>. 1 jlh 
prublrji v.aa. ad:h-:cv,-.l in 1!WT mbii llic .i:il’ 
durlui fur Mil- At'ilNlLI iiiLl*Jc:l llii.- 
■ t-Mccimliililr Tur AjC^ imaiiiaJ ii>S iv.Il-ji 
rciLEiila. in \hiz zuui Jinii i^o 

|mou. I_- ILiliIlvJ iIie ■:Lui lt ||ie- kt-t-u s^inlhr 
H^ikkAd. 


cruu-huLliULiil nipruUriftflJiL*, lu i:bjlil i :n:l 
: i jjErj-j LMiir jJ i il'icftaJi-Jii iiA^JCEUtii>. 


No single orgnni/ntioii is tlit" lend ftgency to 
idtrnlify cross-lunetitmnI requirements. 
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C-I 7 May 1399, tlld Air Fore* CMfll 
Information C'licor Map aqomdnt Board 
(Z IDMB'I o:scalrilflhdd no GRITT to .. 
oevolepa fljp« plan rorpjll iqlcgrhor 
tha requlromontia and ilratogy for 
ach loving j strong and succd-c-arul 
GCSS AF, dloctronlc bUBlneaj And 
olodronk commorte (droit." 1 AjaroMH, 
no GftfTT DroDdBd^ a -tf rabepy bo Idouc V 
a combat iupport chamfrion wltb thd 
authority. reo&onalb ly. and roftourcosi 
to ddliver an Inldq uloo GCE-S--AF (had 
support! Agile Combat Support—an 
ddidnllal olomont of the Eicpodblloriary 
Aoroopaco Force. 

In support of ttihi dffori, tfrfi GRITT: 

- Davolopod a proposal on how to 
organize and proceed to doNne 
GCSS-AF roqulremdnbi, achlavo 
proce-H reenplneorlng, hind and 
Inpewrl 5GSE-AF and Electronic 
Euolr oso'EI&ctronlc Commerce 
[EMCJL 

- Accciwc organ tut I anal structure, 
location, and-fixe. 

- Idanlilldd a load agency :o 

&C 5£»AF Intention acdvIUoa 

- Drafiod a Id ad agency ■: hirer 
defining responsibilities'. 

- Developed rhe business case to 
support Iho recoTimandallone lo 
this report. 

- Drafted an qperabanal requirements 
document iCRC'i and a program 
management a i&ct - #e ;PW Di. 

TTid (dam was also linked bo obtain 
Secretary of t*» Air Fomo.'C^SAF approval 
on no proposal. 
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Ltuation 


■Requirements lead agency. 

Mo single acquisition management 
Mo warfighter confidence in infoil 


on 


manager. 
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l deficiencies 


The Air Force 1 must j-nr 
organizational and o 
to achieve a strong and successful GC 
AF, a hey enabler of Agile Combat Suppq 
for Expeditionary Aerospace Force 
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WhaJC haa chanyfd? 


Eij:uJh Miidij Ak 'Uk-jdL-d Fwtt 

T li. Etfdmimrf A-sw-pi-a V .:i li u l>. Ae 
F*r-r^hur-n ki filial, _aia, i^up.iirJ 
jib-Ui Hill 1 ir- pr-jri^d up-iL'i i&^bklyb 
i a i I - -j a J uf-? BpiLi brtaa Itc ]| h «iei 7 mlnar-p 
rf-ar j iL-rn. Air liYf-u^Jii. r-u-, ffmu uy rk H j_:-.-J m 
il*f 4 #p .ir, a hi:-, il te v-jdJ uZ pu iir^ci 

jjhii 4 haartb. !rl.-J-.rii incpmd jc--nui.'i 4ym 
Zal'.c-iJ t *g i.lTA-AK e- 3 i/^nl hs .ixpp-.'r: M l^a, 
lu, vZ kiL± II'-rL-a f-j.du* L-. .-Mb Air hkj^Jn/i j", 
F^4 


IiiI■ jiiII uIi l-ii Tl-.IiiijI-.-; j ManuJLIIIL--'! 

Kl^jiiii Ac-i nTh 1 =!A| 

Oh ITULA. iUh S A^mu IMPd. kiuad DCi 
kh.Liai w ZtfYikp. .T.i-jiaia. jjrJ li^ilnu-a Vil 
iriPkiikiLdiiH r-l ■ vHirJ .and iciijmZ ibIi--mbji---Ii 
■ i ixj+sirc. Ii aU: itq-xrca iLa =-ri lb ■ r-a a jI tu■ a.- a 
r-T'-.Yi.-«L% h-klr+k ibi l-jibb ia lvI/iti jani iixivi/k-a;. 
Tla hi. .tjjbi*I itZ u.bu^ ki nai 

T^hnuk-av 

Ytifj Itdwl^flll. JI r r LB LE- JkLIk B i k-.TTJJ_--I i IL B 
LkiPi'i'-rkkZ, ■ J_i lzJ*h ak J. irJ. E/LUv-run-. lbi ii. aar.ia 
Wa j»jii t-aaL'k'kJ+- ir-1k±i.■ a dn rf-Eijar-iaJ aUin 
ill-. L^H^ilry p«YiZ* j_ Ai dp. ftiiaa liar., pra x-.. le-v 
l-Lkkk. Oldi J 3BPi »cn C-l K-.1kj.'L'KlkBl 1*1 jlli.li.a-..-. □ 
puiujlu. a links li-Lum:-! 

Spoii C--h-kli'|.'--kiil. Mi'd-Bliiij Ml 
iiiiukVjii. jmJ E r M u i--kiilali-- - 

£ftrj| Zk'.kl.'r-riaai nr^kliap arZ. j-tjiLui/b. ± r J 
aar^n.Tj.rj Jir-ii aj-.1i u ihk Ie-icj E^Mii#flep Fa 
iXpau-ni i Jh I Tfl i rain^x:-a dapak-pnaai nalx 
a a j i a i a j v nb _ a r i iL'i L hJJI ■ i r+- ir.z-.-ii a ui--. a i 
iBkh-'i.'lr-.qp trp au'ahap jb m- idaaiilY aail j.'iraji 
faf kmv mb zeki v-11 ■: I-±j +-. !h rr-i ifl lux- f-u 11 j-f-u is 
Zmr+ auxiE3KYUU-ii jjZ -fail. ik'.kL-f-.Tjiai ■:rjrx:-3d 
a'|.-i a.T j .-Jkili Li a ■■>.tuk-bj 1 kcli ra aria. 

El■ j 11u111p a.- J Pu-bL'---al F:L-al|-!K> 

'A'k xl a^Pi La.a-J v j! .TjJaf-l-. iri-.r|.aBi naaLi u>J 
acDpil, aspanaBLa lira!-., od rai a a i i^l ra a ■ j iy b 
C k-.T-.j-a-J nNk tar La.-.ia “-Ma*! n'a dlj 


bid varfa j - - lk Kkhjj-l.-i:, i:- rf-arji. ar.<=-. allhaodp 
.kid all->.T.Yfllp Pil iil-a a a p a u a k r-.- lj jn d 

J r .Tk±-Jr + l| J-.-.T-T-Ik j. BkJ.-J.Tj 


Wliilu bcllli I III 1 Secrulary and 
( hit'f iif Si ;i IT uf iJk 1 Air I' li-rct 
hal f ilgliil GCSSiAF b j kuy 
A( 'W f nabkr. crLUcul [ii t..Vt 
i-iKLimie. llic Air l''im:L i ti.i n 
me-illuT a iliil>k'> unilieit i isLim 
iiI -CfI SN- Ah n»r ;i chaaipLun 

[|> !l ll 1- IlCil I L- lilt' h ihi.ll IL. 


Limiting Tacki-is 

A laaahki ii-s hauir + I'uhaci pr-TiYtJ ila Air ^ 
ten laaliup a a^i-.-ap Urd -JK'-.kii^lal h'- 

kll^jiLah aL ff-fcfl ila Aa h:-^-.ZiiK-. a ka~i Ti■:a 

*ki OCfl-SJtf U- r u J Viii- 

'■MaI-. tv-b ib« PkLixari irZ^TuI -.-I Sull -.-I ila Air 
Jvrca hj-i-. .-lii-.iKIlI!-:—J.r Lk j A'".-; kB J--lkk .Ltnd 
h-EAF y^^u.d'i .^ir ! JF.'k IkLk.v.iLY.i .i.-LJ--la. laalkZ 
Yiai.'L £r r EOl-Af Bk-r J -.1 ilIf-l-.G HP ■Z.Yfc-.'^k ltd- 

tiu =lu 4 - I hiiiuiilp- LkdJ Auh -vy 

I LTJ El I lUaMh'-lkiJ', -Jl|.-lr.-J L*i I i'-T.TJJI i'-l i A 11 fl B kv 
j■ p3n LkOL^ai -. E parj-■ ■ .kid lapa^v 
r-TXkiK'ki ll--Ai a iajr^---r K .ad 3 Ji-Hi:--.iua.- .'Lki.'aJ- 
□ Baiih.-.'kJ k.-Bi'?.a yffit-r i a I i'-ra n i'-l raqacaadBL-. h 
f-Tk-.kId EYTkprJJK s B nd Jir-Tk-YaaESI iuiuiipu. 

II 1 . Jjlillh'Hk Ei- -.-JBJBIk J-Jl I'-Laia-. IBIBBIJJI.T. 

rkkUia.Tj.IL- L'kl.'lll l!'r. L.'rr.'Hh. KLTJL--lkJ 

r-Tk-kljJ -HY1EJ IB I L-J Ji □Ba:iK-.‘kJ rf-il-Xl -XpHUI ■.- 
mlai L - i±‘i-.T-A-j-larjiL-.-.ii. irjkBUL--.-i !-h>.- ia-j-.n.k 
kk-BlllklLB|? pilliLiBkk BHlXIlLJI Ik- 3^XiprBII£B 
rkkpLT-.laarja l^id^f-x^iaa -uLiiJ latepaaMbilp w 
.tai-”. uthili: 3B r .n.:aal r L ■: u i ■ a. rj ■ iujupi iLa 
ikYklrf-.Tjirj r-: .-kpaiaia il'i_'iK K j j:-.iI .-lbi-jij. ± 


1H 


Appendices 6-84 







1 J bwp fl 




a. ■* 


I:uhji:ui) urwhi rV-r/L. 

hy ^iiihIii A^iiuikiliun Mdiuyunu-’ Ch Jill 
il L3S;-.JiF ijjqj■ ufi rijL^rr.iri u ixZjruJu.r. b-s 
tr-ili i rr--.aiJJi -.ir.'i ■ r-:li:n Jhl a Juaiir-ULiL 
B-.'iY-UIEjM '.VHirill JlI 11 d L-. dr3 K i'-Tl ■ d.'L& 11M 

I rah ■ ■ i'-IIi jiI bak-v ±a Aiiiet Kceacr *= ibs Air 

F-arca i.JiLLfiic.---! i ua^-aui'alB k-i iiBf-L-..T.v.jiiB^ 

EX35-AJ 1 . Ilea eb bL-j- p^fmaa hi Ui-J-.j ihiM 
itcu.-n i'-a tjjj >.r ■ d a -jra jul- duj IlL'.l ir- r■ j■ Llr 
h. 1 lt-.k-Jl i a hi- EX^SX-AF -.s nr-^EVit auk d-dw 
j.Tihxi .yjppHi jjmIijjii.'Il-. j r.viLi ihara \m, 
F.'kiai.J k- id^Idei l/bILeu^ -f oahpk H&ihm 
h- -.■-.-.TJarHi r-Jvtk.1 ^ A J JlL-.^jJh. iu ihl+- kHiUkL 
■ ■jrf htaab ■T-JiId ta rwl.TOl boil t;. a ur+Ca 

>/l| j_i ra-41 aLua. 

hi' h'Huih^lil'Ji L'JIII 1 'Jumiu ill tahMWULiaii 

SupglmJ. 

Mb^jh i ha ir^anaiJiaa aJFP—■■■■! u a an inaal', 
j-.Mr.iL, *r i n_ih.il ita •j.rL.al'iKJ .-aaLa jJiairjm a 
bidejJ iiil.'iiBuiro pin±vj£-.ii. Thaaa a h*E a a 11 h& 
pfxscaaaa iyjjii iidj beJ. _■> iha ?:ni pa-nii t-la^ 

IBB J. IL-J11 IE I JikiL riL-ri-HU -.'I -v* C-T llIB 
L.'bLiLbj-. m -nr a/.Thu j j ? dIoib^l l- -.till J 

ha di julbaB a-fa-Lr vE^ar^ pfuiH 


A. illJ'-Ll -.'I lil.-LT_LL--r. HAHEh/d _aJJ-.J IBJ| lah-hn 
uhiapir^ j -."jr-.ia ni -.jjlIi-.IbI PCES-A ¥ , 
■ pr^kalhp: 

" 1 1 j-.- k ■: i k vi v 1 ! a.a.aj j.i j ■: J Jjll. 

- l/alar.-a aaair.-i aamrt JraifJ-B^inrlrr 

a mala. 

_ li i|-ki iLiijai'-r, .-I tiJl Il.-.I -uJiii; -/Jr J’-ilr?.. 

Mo-EBiEO Sii.yk Wi-iHu- 

ML b"-J-..-anba-. iha bh-i a-z-/--.TjaaidLJ jlj rlr-J■_ 
pTft£?a«. ±rJ NIUliJ p^lfl In?J-.-'i-.lIi.'i~ IKbEJTHi 

ir- a / TjLi k i biiBiii by jh aIa-.”-. 8 ah/ fbibii v rdui a-a 

-HBdia aFafe .'larujirf. Ga-rabm a^pp-an lal.'riLUk-.'i 
rpiBi i a ■ k 11 jji-.i ZIL hX' i/ia;. aaJ L>. luJ a a t>.T a 
r--la lardB .1 lu-.i vl CH Il v jhLi i.lTA^K. 

S4 #m-b. Air F-araa i aI l-txji a-n uraiBru. ahw ~jd 
CHTJ tP-vH 1 iK- lu-a IIILZf h.ahik| >. j 

L'EJTiaihf. ihi:-. ia ru- ai-r-hhrji-.il .-Lr T:i:-a r-iaa ha 
IL-.i lill-KL' IHbmqflBB -HflflUJBBilY w bbbNi A^iIb 
■" a-iabai Hup/n I-lx CKZI/i-AT. ihuia ia ir - diJk'uaJ 
M r Fstl a -/’a J.\-<Jikv'i ■» J-rsL I: p aid :-a-a rd i a re EW 
EC f i'-lk _ i irJ. niaimm “Tl>a b*nreaa 

■:H*5S-AT ill Zll- i:L“ ul k- -dm iLbi iLi>.i:iii a 

piiiia >±^-Ldi t-a Lj-^7iLj'ah| jrlLiL 


Organla^lom-Md Hfljlabo^ihipd- 

li-Ui iL-j^-Lii.r liBahr + - ii Lmaiiiad 3 ^ naiaiJj.iL 
A.«:'T- iiilr-TBLr_-.-E ipiiBi aaadiiS: h Ljpf-L-n ihi 
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* Recognize, understand, and accept one GCS-S-AF 
vision across the Air Force.. 

Ht iwh a r aqu[TBment& lead agency. 

* Streamline GCSS-AF a ppticatiorMnd .integration 
acquisition management. 

■ Improve warfighter confidence in combat support 
information. 

* Consolidate EB.'EC management under GCSS-AF. 

v Develop and use hey measures and metrics. 
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R b'jL'jiiifb. widtiTiLWA. tad ACM pi 

mib CCiS-A- vikiuii vji-.'kh 'hk Ai- 
Fi-fck EmiU-ulu uiiJ iiib-T L.T mmuI m 
QCE lS-AF. 

ltd Cil ai!—Al l-LT-T. LLU- rn/l hk L>. Ull^ldee 1 rJ. 

df -3-.-~.~u^ diaum qjt iB^lp, leaiaj-i.. aJ iiuuI 
AOS i■ I a ri l dhH mil ih■ ippuprui Irr-J -.-I ■uurr i . 
■ I-ji lid Ki.7iJiiir-.Mi>. Aeraipied !e-r-a-i ir- 

■ IllL'I VIH All TaiV-a .T_- JIi'H i ihlvlpli/u ~jil lull 
ipeeciii e-l xilni>, r-peuL-Hd. 

ltd ftEllJJ-JI IK* I* tf iNl IT- J-.-.TJIIIh'UI Hi 
lUhL", 1 -OJIlLdd .illJIJV. ±rJ 'llr.l 1 II . Ill.TlLdl.'l L'kri 

mil K-l ehJ is Jape .drJ iLline di, Kirie .-pda-.. JUbr 
iVlL" j' .'lYm'i _-.l--aiiJiiaii li-.-ii er-nbn npp-an 
LIk-ZT-LL- Hi rf.y- 31 £ n 1-1 1»3 JI Jl JXj: Ji ue real-nirs 
Ir-r .TJa-ir-id ii .ns laarxea □ Ciimfld OK 5 £i-AT 
□ lamnni nur ilu- l.tjl'iII ■» iiie ihe liuteoi 
■ d-.ili -.'I -±j. '-L-aa-.m_u. Aar !--jJI lueir-rjl ami. aM 
a-.-anui Jda-. ii jJI In eU. 

A ehaiiaiai u .T-MikiJ i:- aKhaeiKi ilrj >I 8 LrHS-A.P 
i l-jii. Ttd -.1 onph >3 .TJin lUT-. i hi irud lai CTO- 
Aff JaJ IL-. I L-J JI r-3 U-j^kldiV-iL 

UnUrt* A luijui- WniiLA laid d-jumy DoluM 
Oil ■amnl'dl. hjppCiH imufrfiAira luqubiFiiy nil. 
ul llih IIhIiIu- Mdd l m j ifnpklii ubA IIi-j 
E.'.| lhJ ULIIId'h' Adi I'k+adlU F'JI L>J. L--_- - -h I h-L-ri 11 1 

■ ILh JvjL'' 0 diiJ Ail FtfMOiU 
EnflVUYUflE. 

■T-.mpr-jiJ nrLiiarol UlI r-apaiLerjimei nJ 
iqEl. IhI LkjJ .4%UH Mil 

r i:>L>.Lii-f- li-hit-.j .t_uo|.-. >:;i j.k v j.-ii»hLi 
iiiL aar.hu dippe-n inli'-riiinar. 1 ■ 11 pr■ 1 m 

n^urnwE 

r IJaarak a-iciJja. piaa-.m-a.- lai 'ai-Liu-. pir-r-n.-. 
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The ease for GCSS-AF is 

.GCSS- 

AF in an essential enabler for 
ACS—a key to EAF success. 
Initial return ■on-investment 
analysis suggests only small 
quantifiable financial savings 
might be achieved across combat 
support. However, GCSS-AF 
brings 

essential to meet the needs of the 
. These would be more 
difficult, if not impossible, to 
achieve without GCSS-AF. 
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|n^cinHTimbCS&ftrrw|ifliiniitnb . II If i ccummund*] 

■ Apjrtvowlho ^ 

■ EaiawrsiJiifecsaySFspbr 

■ CSAF Sigh a ihu-a's-agc ilirtCluiq •ab-ai'tCjir;.:'? in £ompJafin£ tlh laa-k:- 
□uLlinc-d in fchn I uad agency c li arler. 

■ Dirtcl rhuL all Air Frrtte uom bar s»u ppu-rL Syateltii intugr a[L' irtta GC3S- 
AF and -aoniFilv with ils a-landuida. 
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rom the GRI1 i Senior Advisory Group 

tte must plan u.nd execute our deplcymunl activities faster and marc 
accur utely than wu da today if wu 're la effucEivuly pul bombs- on tai geE 
Within 40 hour's. Cur ru ill planning proLos-ses da mat udoquaEuly support 
employment of Ihe Expudittoii-ary Aeros-pucu Forcu^ |EATj primary Pu-isif 
element, Qri Air Expeditionary Force |AEr|. Wo need tools Lo support 
rapid ACT employment with reduced deployment footprint. Tills will 
enable us to carry more teeth to the figliL and. thus. increase our tooth- 
Lchtait ratio. 

AILhough odr forces and support si lem enls pu rfa i m u d superbly in 
Kosova, Me relied toe much art brute Farce. long hours ever ihe 
telephone, and W high-qualily purple. As wo beiiom u Ioann i and face 
now and differu ul challenges, wu m ust uchi uve now luvels af integraLud 
capability. We need to effectively amploy new technologies being 
exploited today in the commercial sector—■such as smart cards; Web* 
b i owsu r-enab led b u s int'ss prOcu uses provid irig real-dim# updates of 
support stains, from ammun iti on balances to individual shel record 
statuses; and integrated Views c-f i n tormaEi on acress outf functional 
conmiuniEies—to true our personnel to CMfy thu light to etir aduorsurius 
rather Lli uri stuff phone bunks la colluot suppc-i L tUlIL 

GCSS-AF, as a system of systems. is die principal teal that will deliver 
Agile Combat Support to the AEF. If the Air Faroe is to achieve the EAF 
vision, iheti the leadership must Stand Strong bi'hind Ihe GCSE Ar 
program, focus the ru II uli onal com inun ities c-n the mission value, and 
etk'ctivuly impk'numt the recommendations of the GRITT. 



f J Goidon E. Forneli Harold W. Sorenson 

^ Dayian Aerospace, Inc. The MITRE Corporation 




John Foreman 

Software Engineering Institute 


Bob Majors / 
Ihdependanl Consultant 
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Appendix 61 

GCSS Capstone Test and Evaluation Master Plan (TEMP) 

(See PDF File) 
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Appendix 6J 
DODIIS Test Process 

Explanation of Department of Defense Intelligence Information System (DODIIS) 
test process: 

The DODIIS test process is an iterative process that follows the software item through its life 
cycle and assesses items continuous improvement towards meeting installation and integration 
requirements. The DODIIS testing team evaluates the testing requirements for each new 
software release early in the development cycle. The DODIIS development and testing process 
is detailed in the DODIIS Instructions document, which relates the process to DoDD 5000 series 
acquisition milestones. 

DODIIS software products strive for one major release and one minor release yearly. Major 
releases generally add new functionality or interfaces or make other large scale changes to the 
software. Minor releases upgrade COTS or GOTS components and/or provide limited 
enhancements. Software “patches” are generally minor changes to provide corrections in 
response to user software problem reports and do not have to be tested under the DODIIS 
process. 

The development program office is responsible for certifying Factory Acceptance Testing (FAT) 
has occurred and all documentation and other deliverables are acceptable. The FAT often 
involves a sampling of operational users. 

The Joint Test Planning Meeting (JTPM) brings together all players (integration testers, security 
certifiers, interoperability testers (JITC)) to plan specific testing activities for a new software 
release as well as the resource requirements. 

During Beta I testing the item is brought into an independent Government facility and turned 
over to the DODIIS testers. DODIIS testers check the ability to install and integrate the software 
into the DODIIS infrastructure (i.e., integration with COE environment). Security certification 
generally occurs at the Beta I test. 

Beta II testing is typically conducted at an operational site. The JITC generally conducts 
interoperability testing (testing of interfaces for passing data between systems) at the Beta II site 
unless the interfaces and data are available at the Beta I government facility. 

Training certification occurs in parallel to this process by the cognizant training organization. 

The results of FAT, Beta I and Beta II tests are collated within 5 business days and attached to an 
Acquisition Decision Memorandum (ADM) prepared by the SPO. Specific recommendations 
are made relative to deploy/fix before deployment/fix and retest. The ADM is submitted the 
DODIIS Management Board (DMB). DMB is chaired by DIA and consists of voting members 
from each Service, the Unified Commands and other DoD IC Combat Support Agencies (NSA, 
NIMA, NRO). DMB makes a decision relative to deployment or other action. 
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DODIIS relative to OT&E: 


There is NO conflict at all with AFOTEC or any OT&E organization. The DODIIS testing does 
not replace, and in some cases has been done in coordination with formal OT&E conducted by 
the various responsible service organizations. Joint Collection Management Tool (JCMT) is an 
example. AFOTEC came to the JITF to prepare for an OT&E they were going to be conducting 
at an operational site, and participated in the Y2KISR testing done here last year. 

It has been noted that better communication and coordination with the various service OT&E 
orgs needs to be developed. INSCOM has participated in the DODIIS Test Study (ARMY 
OT&E). The DODIIS Test Study is the need to involve ALL testers throughout the software 
lifecycle. DODIIS has the Air Force and Army directives and regulations on testing, which 
mesh very well with how DODIIS does/”plans to do” business. 
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Initial Distribution 


Headquarters Air Force 

SAF/OS 

AF/CC 

AF/CV 

AF/CVA 

AF/HO 

AF/ST 

AF/SC 

AF/SG 

AF/SF 

AF/TE 


Secretary of the Air Force 
Chief of Staff 
Vice Chief of Staff 
Assistant Vice Chief of Staff 
Historian 
Chief Scientist 

Communications and Information 
Surgeon General 
Security Forces 
Test and Evaluation 


Assistant Secretary of the Air Force 


SAF/AQ 

SAF/AQ 

SAF/AQI 

SAF/AQL 

SAF/AQP 

SAF/AQQ 

SAF/AQR 

SAF/AQS 

SAF/AQX 

SAF/MI 

SAF/SN 

SAF/SX 


Assistant Secretary for Acquisition 

Military Director, USAF Scientific Advisory Board 

Information Dominance 

Special Programs 

Global Power 

Global Reach 
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